You don't need to even authenticate salt, because if it gets corrupted or maliciously modified (same thing :), decryption will inevitably fail.
"Associated Data" is something if you want available in the clear not encrypted. One example would be fields of the IP packet header. So if you protect your IP traffic via IPsec or such, it would make sense to use AEAD, encrypting the packet payload, but putting the packet header (well, some of its fields - because there are fields that must change with each Internet hop) in "adata". Reason - that IP packet will probably go through many routers on its way from its source to destination, and unless it's header data is in the clear, those routers won't be able to pass the packet to its destination. In other words, consider an example: you're writing a letter to somebody, and want it delivered by postal service. The contents of your letter must be opaque to anybody but you and your recipient, and you also want to protect it from modification by somebody else who might get hold of that letter. So what you write in your letter is the candidate for "pdata". What you write in the envelope - cannot be encrypted, or post office won't be able to deliver your letter. On the other hand, you don't want the delivery address and/or the return address to be modified - and if it was modified you want it to be detected. So what you write on the envelope is a good candidate for "adata". Yes, it s a requirement that if AEAD fails to either decrypt or authenticate the pdata, or fails to authenticate adata (if present - but it detects when adata was resent during encryption but was not provided during decryption) - the whole decryption is considered as failed, and error must be returned to the caller. Some implementations may also (in addition to the error code) provide the caller with whatever plaintext they did recover - there's an argument whether such behavior is legal or not. BouncyCastle (Java) and Oracle Java throw an exception. I don't remember whether Crypto++ returns an error or throws an exception - you can experiment and report here (or look at the source :). Sent from my iPad > On Feb 25, 2015, at 13:31, Ilya Bizyaev <[email protected]> wrote: > > Hello! Thanks for replies! > 1) Jean-Pierre Münch wrote: > "This is mainly data that you must authenticate because of your protocol. In > your case you might want to authenticate the salt with the header GCM > execution." > So, you mean that the salt can be stored not in the header, but in the AAD > channel before it, don't you? > 2) " so can simply put "ef.ChannelPut("AAD",data,data.size());" > The ChannelPut function seems to cause no problems; the problem is in > AuthenticatedEncryptionFilter constructor's second argument, which is of > BufferedTransformation pointer type; I'll try to provide it with SecByteBlock > link, but I don't think this would work. > 3) Mouse wrote: > "It's typical use is integrity-protecting message headers that must be > available in the clear to the intermediate nodes to properly route this > message." > I'm afraid my level of English is not enough to understand this sentence; > could you please explain it simplier? > 4) And if decryption goes wrong, will AEAD return any value or throw an > exception? > -- > -- > 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. -- -- 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.
smime.p7s
Description: S/MIME cryptographic signature
