4 ms·

CBC is okay if it is used to encrypt before MACing. The issue is that TextShredder used CBC without any authentication, i.e. a MAC. That means someone can modif

by sweis 13y ago

CBC is okay if it is used to encrypt before MACing. The issue is that TextShredder used CBC without any authentication, i.e. a MAC. That means someone can modify the ciphertext in transit and it won't be detected. This opens up several types of attacks. In theoretical terms, unauthenticated block ciphers are not secure against adaptive chosen ciphertext attacks (CCA2). In practical terms, one attack that comes to mind is a padding oracle attack. Essentially, an attacker given a real message and can create modified ciphertexts that will cause a decrypting party to potentially leak information in a side channel. Serge Vaudenay talked about this 12 years ago: http://www.iacr.org/cryptodb/archive/2002/EUROCRYPT/2850/2850.pdf http://www.iacr.org/cryptodb/archive/2002/EUROCRYPT/2850/285... The recent Lucky 13 attack was a form of this type of padding oracle attack: https://www.imperialviolet.org/2013/02/04/luckythirteen.html https://www.imperialviolet.org/2013/02/04/luckythirteen.html

danbruc 13y ago
I understand the point in the general case but I don't think you could exploit it in this case. Nonetheless it would still be nicer if the application would tell me that someone tampered with the message instead of making me infer it from the fact that it partially decoded into garbage. Thanks!
- stevehaunts 13y ago
  I will add in a hmac if the ciphertext and IV and alert the user if the message has been tampered with. I will have it updated within the next week. Thanks for the constructive feedback. This is why I posted it here and made it open source so I could get peer review, make the utility better and learn a few things along the way.
  - danbruc 13y ago
    One thing I would really suggest is to get rid of all this conversions between strings and byte arrays, this adds unnecessarily complexity to the code. Convert messages and passwords to byte arrays as soon as you get them, preferably using a Unicode encoding to support foreign languages, and then only work with byte arrays for everything until you finally want to output the encrypted message where you probably want to Base64 encode it. Especially I did not understand why you have these ugly methods in ByteHelpers when you already have Encoding.GetString() and Encoding.GetBytes() and you are using them in some places.

by sweis 13y ago

danbruc 13y ago

I understand the point in the general case but I don't think you could exploit it in this case. Nonetheless it would still be nicer if the application would tell me that someone tampered with the message instead of making me infer it from the fact that it partially decoded into garbage. Thanks!

stevehaunts 13y ago
I will add in a hmac if the ciphertext and IV and alert the user if the message has been tampered with. I will have it updated within the next week. Thanks for the constructive feedback. This is why I posted it here and made it open source so I could get peer review, make the utility better and learn a few things along the way.
- danbruc 13y ago
  One thing I would really suggest is to get rid of all this conversions between strings and byte arrays, this adds unnecessarily complexity to the code. Convert messages and passwords to byte arrays as soon as you get them, preferably using a Unicode encoding to support foreign languages, and then only work with byte arrays for everything until you finally want to output the encrypted message where you probably want to Base64 encode it. Especially I did not understand why you have these ugly methods in ByteHelpers when you already have Encoding.GetString() and Encoding.GetBytes() and you are using them in some places.