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 Am Montag, 16. Februar 2015 03:22:17 UTC+1 schrieb 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 > > >> Am Freitag, 13. Februar 2015 18:18:06 UTC+1 schrieb 雷骜: >>> >>> 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, >>> >> -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
