I am working with a client that requires the use of secureFTP for file transfer and is also advocating the use of sLift EZ Classic (command-line file encryption using PKI) on top of SFTP.
Is this overkill?
In direct response to "how secure is SFTP", the latest version of OpenSSH supports up to AES-256, 3DES and Blowfish.
As to whether you need to encrypt the document before transferring it, it depends on what you're trying to achieve. Barring some breakthrough in quantum computing, the time it will take to brute-force a stolen SFTP data stream is not within reason any more than the time it will take to brute-force a stolen SFTP data stream containing an encrypted file.
The advantage to encrypting the document before transferring it is that when the file arrives at the remote end (which could be unattended - i.e. email), it's not directly readable. Someone has to come along and fire up the userland decryption tool and enter their credentials in order to turn the received file into something usable.
The cost of doing so is more work for users at either end. Plus, SFTP isn't going to know that someone is sending a file that hasn't been encrypted already, so a lack of user training or discipline could easily erode the advantage I stated above.
I would have thought sftp would be sufficient most situations. Its basically ftp through ssh. Although I guess that's up to the client.
I'm guessing main advantage of EZ-Lift classic is for making sure the users generate adequate quality keys. I have to admit, there is not much point in ssh if the keys are weak.