4 ms·

I couldn't help but notice that the original SSH key was encrypted with AES-128-CBC and the "more secure" one mentions 3DES in the ASN.1 structure. This makes m

I couldn't help but notice that the original SSH key was encrypted with AES-128-CBC and the "more secure" one mentions 3DES in the ASN.1 structure. This makes me question if the "improved" SSH key really is more secure. I'm not an encryption expert. Can someone else weigh in on this?

apawloski 13y ago
The reason 3DES is avoided is because it is significantly slower than AES and usually leads to generally poorer performance. Security-wise, it's fine to use if you're willing to make these performance tradeoffs (eg, you might want it for backwards compatibility with some ancient DES-friendly system).
- tytso 13y ago
  The fact that 3DES is slower is actually an advantage if you are trying to prevent against brute-force attacks. Given that we are encrypting binary data, it's unlikely that knowledge of the plaintext (for example, knowing that it's probably US-ASCII and so the 8th bit is probably always zero) is not going to be available to the attacker. Other potential attacks, such as related plaintext attacks, will also not be available to the attacker. Given that brute force attacks are the most likely threat scenario, using a 3DES which is slower is a reasonable choice.
  - jholman 13y ago
    Double-negative in your second sentence, and I think it's not what you meant. I wouldn't be so pedantic, except that crypto is worth being pedantic about.
- davidcuddeback 13y ago
  Thanks for the replies. I'm certainly no expert on this stuff. A few years ago, I implemented DES as a learning exercise [1]. I recall reading something at the time about security concerns with DES. That was several years ago, so I'm probably mis-remembering. Wikipedia vaguely refers to concerns about security being a motivation for AES, but doesn't explain what those concerns were [2]. [1] https://github.com/dcuddeback/des_crack https://github.com/dcuddeback/des_crack [2] https://en.wikipedia.org/wiki/Data_Encryption_Standard#Replacement_algorithms https://en.wikipedia.org/wiki/Data_Encryption_Standard#Repla...
  - TheCondor 13y ago
    Key and block size were the concerns. Key size specifically. Cryptographically speaking, DES has been incredibly good and resisted pretty much all attacks but the key size has made brute force feasible.
gingerlime 13y ago
I believe you can tweak the algorithm to suit your requirements, e.g. openssl pkcs8 -topk8 -v2 aes-128-cbc -in ~/.ssh/id_rsa -out test_rsa_pkcs8 As far as the strength of AES vs. 3DES, the difference is probably negligible for most practical purposes. AES is however the newer standard, and is more flexible, performs better on different hardware etc, so seems like an overall better choice, but I would say not so much for any practical security properties. (i.e. both are pretty strong).
- vrdabomb5717 13y ago
  You can get a list of the available cipher commands with openssl list-cipher-commands A description is available if you do man enc Doesn't seem to be any reason you couldn't use AES-256-CBC if you wanted to. Not a security expert though, so other than speed concerns, I don't know the repercussions of doing so.

apawloski 13y ago

The reason 3DES is avoided is because it is significantly slower than AES and usually leads to generally poorer performance. Security-wise, it's fine to use if you're willing to make these performance tradeoffs (eg, you might want it for backwards compatibility with some ancient DES-friendly system).

tytso 13y ago
The fact that 3DES is slower is actually an advantage if you are trying to prevent against brute-force attacks. Given that we are encrypting binary data, it's unlikely that knowledge of the plaintext (for example, knowing that it's probably US-ASCII and so the 8th bit is probably always zero) is not going to be available to the attacker. Other potential attacks, such as related plaintext attacks, will also not be available to the attacker. Given that brute force attacks are the most likely threat scenario, using a 3DES which is slower is a reasonable choice.
- jholman 13y ago
  Double-negative in your second sentence, and I think it's not what you meant. I wouldn't be so pedantic, except that crypto is worth being pedantic about.
davidcuddeback 13y ago
Thanks for the replies. I'm certainly no expert on this stuff. A few years ago, I implemented DES as a learning exercise [1]. I recall reading something at the time about security concerns with DES. That was several years ago, so I'm probably mis-remembering. Wikipedia vaguely refers to concerns about security being a motivation for AES, but doesn't explain what those concerns were [2]. [1] https://github.com/dcuddeback/des_crack https://github.com/dcuddeback/des_crack [2] https://en.wikipedia.org/wiki/Data_Encryption_Standard#Replacement_algorithms https://en.wikipedia.org/wiki/Data_Encryption_Standard#Repla...
- TheCondor 13y ago
  Key and block size were the concerns. Key size specifically. Cryptographically speaking, DES has been incredibly good and resisted pretty much all attacks but the key size has made brute force feasible.

gingerlime 13y ago

I believe you can tweak the algorithm to suit your requirements, e.g. openssl pkcs8 -topk8 -v2 aes-128-cbc -in ~/.ssh/id_rsa -out test_rsa_pkcs8 As far as the strength of AES vs. 3DES, the difference is probably negligible for most practical purposes. AES is however the newer standard, and is more flexible, performs better on different hardware etc, so seems like an overall better choice, but I would say not so much for any practical security properties. (i.e. both are pretty strong).

vrdabomb5717 13y ago
You can get a list of the available cipher commands with openssl list-cipher-commands A description is available if you do man enc Doesn't seem to be any reason you couldn't use AES-256-CBC if you wanted to. Not a security expert though, so other than speed concerns, I don't know the repercussions of doing so.