> The more important question, however, is why did the alleged "needless use of
> RSA" trigger such a huge red flag for you? What is the reason we should not
> use RSA?
Because public-key cryptography, while being super awesome and very useful in
many situations, is orders of magnitude slower than private-key
Wow. All of this over performance? I was prepared to hear some convoluted explanation about security, but performance got you so angry?
Unless you are backing up 10,000 files with an average length of 10 bytes, the time for performing 10,000 RSA decryptions is negligible compared to the time it will take to actually encrypt said 10,000 files (not to mention, store the to the disk and/or transmit them over the network). I will gladly accept counter arguments if they are backed up by actual data.
For the record, here are my own tests, from a few seconds ago. All tests on an SSD:
Create 10,000 files with 10 bytes of zeros. Time output:
Encrypt said 10,000 files with rsyncrypto (including symmetric encryption and compression) with a 1024 bit RSA certificate:
Encrypt said 10,000 files with rsyncrypto with a 2048 bit RSA certificate:
To me, spending the extra 1.7 seconds (CPU time, much less for wall time) for 10,000 files no one in his right mind will even want to back up is negligible.
When I hear about hard-disk I/O and synchronization
Who even brought it up? The only context in which I said "synchronization" was machine to machine synchronization: i.e. - rsync.
It seems to me like you are thinking of using rsyncrypto for purposes vastly different than the ones for which it was designed for. That's fine, of course, but complaining that it does a poor job there is off topic and redundant. Rsyncrypto is not built for full disk encryption. It is built for using untrusted storage for backup over a network. This is not everyone's need, but it is both the story poster's need and the original commenter.
Moreover, even if you do use different keys for each file,
those keys can still be encrypted with symmetric crypto.
Yes (well, no, see later), but why WOULD you? Like I said above, the performance argument is bull, and you do lose capabilities.
As for the backup example, that does not make much sense.
I have no idea what you are talking about, which leads me to believe you did not understand what I said. What I said was that you might back up several machines to the same storage provider. Using public key allows you not to have your entire data compromised by having one of those machines compromised. Also, not needing your master decryption key in order to encrypt means the chances it gets compromised are, more or less, zero.
Do not get me wrong. This is not personal and I'm not attacking you, so stop
being so defensive. I simply made an initial comment that the devs don't seem
to know what they're doing in regards to crypto, and then you challenged me and
I simply detailed why I made the claim. I appreciate and respect open-source work, but
unless you can back up your design choices with pertinent arguments, try to
swallow criticism more easily. There's a reason why "don't make your own
crypto" is a rule of thumb for programmers. Unless you're working in the
field, let the experts deal with this. Or go study. "I have some crypto
knowledge" is not enough to justify modifying existent mode of operations such
In order for you to be able to pass the above passage as likely, you should have done two things. You did neither. You needed to:
1. Show an actual design failure. At best, all you did was show a dislike to RSA due to performance reasons, which you failed to back up with any sort of actual data.
and, more importantly
2. Show that there is a standard solution to the problem at hand, which would have made designing redundant.
Had you done either one of the two, I'd have still thought your comment vein and condescending, but at least I would have felt I am smarter for it. As it is, all you did was show a prejudice against anything that uses RSA where you believe it unnecessary (unexplained and unsupported), without showing a single alternative. It's not as if you are claiming that CBC solves the problem, or that CTR does not suffer from the problems I claimed it does.
Cryptography (which I have studied, but I do not consider myself an expert in all fields of it) is all about trade offs. If it weren't, one time pad would be the only algorithm anyone would ever use. As the list of constraints changes, so does the compromises that need to be done. Rsyncrypto is a compromise. This is clearly stated anywhere you look. If that compromise does not work for you, that's fine. It does not mean, like you stated, that I (not "devs" like your recent backpedaling attempt tries to make it), who made it, have no idea what I'm doing.
And it's funny to me that you call my responses defensive, merely because I am putting you on the spot to justify the (to me) ridiculous statements you are making under the guise of being a cryptography expert. Like you said: unless you can back up your assertions with pertinent arguments, try to swallow criticism more easily.