How to know if decrypt is correct (AES or ECIES)

[雷骜]

Hi everyone:

I'm new in Crypto++

Recently I'm focusing on AES and ECIES decryption. I wonder if there has some way I can know if decryption receives the correct result?
(In sign and verify, it returns a bool variable so that I know if the signature is correct, but in decryption schemes it don't has this kind of things)

Thanks a lot,

Best wishes,
Lei

[Jean-Pierre Münch]

Hey Lei,

If you just want to make sure, a receiver dan decrypt the data, you may want to try to to decrypt the data before sending / storing / whatever it. Then you would simply check if the orirginal message equals the encrypted-decrypted message.
If you want to make sure that you received correct data, there are several possibilities:

1. Integrity checking: Append a Hash to the end of your message (before encrypting it) and check the hash after decryption. (M' = E(M||H(M))), Hash-Functions are: SHA-512, SHA-256, SHA-3-512,...
   
2. Authentication: Append a MAC-Value to the end of your message (like in 1), but this time you choose a MAC scheme, providing you the information that the sender actually sent and knew the data. You may want to use HMAC, VMAC, ...
3. Authenticated mode: You may also use (for AES mainly) and authenticated encryption mode which can provide you the neccessary assurances as it has an authentication mechanism included. You may want to use EAX or something similar

Usually I prefer to use Method 2 vor symmetric data exchange (-> CTR-AES) and method 1 for asymmetric data exchange (-> ECIES).

BR

JPM

[雷骜]

Hi Jean:

Thank you so much that really helps a lot.

在 2015年2月14日星期六 UTC上午10:11:30，Jean-Pierre Münch写道：

[Jeffrey Walton]

For AES, you will need to either (1) use an authenticated encryption mode or (2) add a MAC to a confidentiality mode. For (1), use EAX, GCM or CCM mode. For (2) use CBC mode for confidentiality and an HMAC or CMAC for authenticity.

References for (1) are at http://www.cryptopp.com/wiki/EAX_Mode, http://www.cryptopp.com/wiki/GCM_Mode and http://www.cryptopp.com/wiki/CCM_Mode.

References for (2) are trickier because they require you to combine the primitives. See http://www.cryptopp.com/wiki/Authenticated_Encryption for starters.

For ECIES, you don't need to do anything. The system has an authentication tag built into the system. See http://www.cryptopp.com/wiki/Elliptic_Curve_Integrated_Encryption_Scheme.

In the cases of using an authenticated encryption mode or ECIES, the library will throw an exception if the authentication tag detects tampering.

[Jeffrey Walton]

On Saturday, February 14, 2015 at 5:11:30 AM UTC-5, Jean-Pierre Münch wrote:

Hey Lei,

If you just want to make sure, a receiver dan decrypt the data, you may want to try to to decrypt the data before sending / storing / whatever it. Then you would simply check if the orirginal message equals the encrypted-decrypted message.
If you want to make sure that you received correct data, there are several possibilities:

1. Integrity checking: Append a Hash to the end of your message (before encrypting it) and check the hash after decryption. (M' = E(M||H(M))), Hash-Functions are: SHA-512, SHA-256, SHA-3-512,...
   
2. Authentication: Append a MAC-Value to the end of your message (like in 1), but this time you choose a MAC scheme, providing you the information that the sender actually sent and knew the data. You may want to use HMAC, VMAC, ...
3. Authenticated mode: You may also use (for AES mainly) and authenticated encryption mode which can provide you the neccessary assurances as it has an authentication mechanism included. You may want to use EAX or something similar

I believe (1) and (2) above are insecure and you should not use them. I'm pretty sure (2) is SSH's scheme, and we know it has problems.

As far as I know, there's only one way to combine a confidentiality mode and an authenticity mode and have it result in something that's generically secure. That's an Encrypt-then-Authenticate (EtA) scheme.

See Krawczyk's "The Order of Encryption and Authentication for Protecting Communications" (http://www.iacr.org/archive/crypto2001/21390309.pdf) or Authenticated Encryption on the Crypto++ wiki (http://www.cryptopp.com/wiki/Authenticated_Encryption).

Jeff
 

[Jean-Pierre Münch]

Hey Jeff,

I meant (2) to be AtE as stated in the paper you referred. (-> SSL)
I didn't know about this so I went lucky as Crypto++ only provides CBC, CTR, OFB, CFB and ECB (of which only ECB seems vulnerable), so (2) should be secure according to the paper.
Of course authenticated encryption is easier to use.

I did even believe that EtA wasn't secure as it didn't guarantuee the sender to have known the plaintext. But now I know better :)

I wouldn't use (1) in practice because a dedicated MAC is always better. Maybe it would "count as"  a MAC in the context of the paper, although I don't know if a keyed Hash (=MAC) is required.

I'll remind me to EtA in the future. Thanks Jeff.

BR

JPM