Hacker News new | ask | show | jobs
by upofadown 52 days ago
I stated that it was possible to use RFC-4880 in a way that is completely secure, not that every possible use is completely secure.

Your example mentions 3DES. 3DES is secure. The reason it is not recommended is because 128 bit block lengths allow longer file/message lengths than 3DES can accommodate on one key. At any rate, RFC-4880 permits the use of AES and that is what is normally used.

1 comments

This is incongruous with your original argument: AES is optional, so anybody doing cold storage with PGP on messages they don’t fully control (again, the backwards compatibility story) is going to end up using 3DES.

And no, you can’t brush aside 3DES being insecure for large messages and then call it secure. Modern cryptographic tools don’t allow that, because there is (again) universal consensus that it’s insecure.

There are no preferences available for symmetrical encryption. GnuPG for example does AES for symmetrical encryption by default. Is it violating RFC-4880? I think things get philosophical here.

I doubt that there is an implementation left that does 3DES by default.

It would be nice to update the standard to make AES required to be available for decryption. I really wish that the most recent standard update attempt had restricted their scope to such uncontroversial changes before going to war over the controversial changes.

That’s still incongruous with your original argument: using AES for long term encryption isn’t (particularly) controversial, but using it via a scheme that only mandates 3DES absolutely is. The default is immaterial in the setting being discussed, since for compatibility you don’t get to control how the data was originally encrypted.

Edit: I say “particularly” because I don’t think any cryptographer would endorse 4880’s only mode of operation for AES.