Hi Jay,Ah - here's the start of the discussion. It seems to me like you've correctly understood the details of the operation of SignedSessionEncrypter / Decrypter. And it is indeed is meant for current use - it is not just for interoperability.
As for the motivation, I hope I can help. The core motivation is that RSA encryption / decryption is slow while AES is fast.So SessionDecrypter will create a shared AES key that is protected by RSA encryption that can then be used to encrypt a lot of data relatively quickly. However, since only the public RSA key is needed to establish the session, the sender could be anybody. SignedSessionEncrypter goes the next step - by including a signature with each piece of data, so you know who encrypted it.So when you say "the encryption is already authenticated", that is only partly right: it is already authenticated as part of the session, but it is not authenticated as coming from a known party. One could argue that signing each piece of data is unnecessary, if the session material itself was signed, but signing each piece of data proves authenticity directly, instead of requiring it to be inferred, thus limiting the attack surface.
As for the nonce, it is not there to prevent replay attacks, it is required as part of the signing / verification process.Neither SessionDecrypter nor SignedSessionDecrypter will prevent replay attacks. Since they only support one-way communication, the receiver gets the data from the sender with no possibility of providing some kind of once-per-transaction salt. Replay prevention has to be handled elsewhere in the protocol (by, for example, asking the sender to create a unique ID and having the receiver store the IDs for comparison.)
Happy to discuss more, particularly if I've misunderstood something myself.
As for the motivation, I hope I can help. The core motivation is that RSA encryption / decryption is slow while AES is fast.So SessionDecrypter will create a shared AES key that is protected by RSA encryption that can then be used to encrypt a lot of data relatively quickly. However, since only the public RSA key is needed to establish the session, the sender could be anybody. SignedSessionEncrypter goes the next step - by including a signature with each piece of data, so you know who encrypted it.So when you say "the encryption is already authenticated", that is only partly right: it is already authenticated as part of the session, but it is not authenticated as coming from a known party. One could argue that signing each piece of data is unnecessary, if the session material itself was signed, but signing each piece of data proves authenticity directly, instead of requiring it to be inferred, thus limiting the attack surface.Okay, I can see that if the session material were signed, that only relying on the MAC could allow forging from the sender if the recipient's private crypt key was compromised. However, the session material is not signed, so even though you can't forge encrypted messages from the sender, an attacker can forge session material without any secrets compromised, which seems kind of arbitrary and unexpected. But I guess when thinking of it this way, I can think of not signing the SessionMaterial as a bug, rather than a design choice. Thoughts?
As for the nonce, it is not there to prevent replay attacks, it is required as part of the signing / verification process.Neither SessionDecrypter nor SignedSessionDecrypter will prevent replay attacks. Since they only support one-way communication, the receiver gets the data from the sender with no possibility of providing some kind of once-per-transaction salt. Replay prevention has to be handled elsewhere in the protocol (by, for example, asking the sender to create a unique ID and having the receiver store the IDs for comparison.)Well I'd really like to know, what the intended purpose of the nonce is. It's used in the signing, but is it to keep signed data from one session from being verified in a different session? The MAC is going to do that too. Maybe the design of this api is just ignoring the fact that there is a MAC? It seems pretty wasteful, but I guess i can understand that. I just want to make sure I have a clear understanding, so i can convey appropriately in the API.
On Wed, Jan 2, 2013 at 1:30 PM, Jay Tuley <j...@tuley.name> wrote:
As for the motivation, I hope I can help. The core motivation is that RSA encryption / decryption is slow while AES is fast.So SessionDecrypter will create a shared AES key that is protected by RSA encryption that can then be used to encrypt a lot of data relatively quickly. However, since only the public RSA key is needed to establish the session, the sender could be anybody. SignedSessionEncrypter goes the next step - by including a signature with each piece of data, so you know who encrypted it.So when you say "the encryption is already authenticated", that is only partly right: it is already authenticated as part of the session, but it is not authenticated as coming from a known party. One could argue that signing each piece of data is unnecessary, if the session material itself was signed, but signing each piece of data proves authenticity directly, instead of requiring it to be inferred, thus limiting the attack surface.Okay, I can see that if the session material were signed, that only relying on the MAC could allow forging from the sender if the recipient's private crypt key was compromised. However, the session material is not signed, so even though you can't forge encrypted messages from the sender, an attacker can forge session material without any secrets compromised, which seems kind of arbitrary and unexpected. But I guess when thinking of it this way, I can think of not signing the SessionMaterial as a bug, rather than a design choice. Thoughts?Hmm. I wasn't in on the design process, so I'm just speculating. I would imagine the thinking was that the authenticity of the payload was the important part, and that given that the payload signature could be verified, signing the session material also felt redundant. But like I said, I'm speculation now.
As for the nonce, it is not there to prevent replay attacks, it is required as part of the signing / verification process.Neither SessionDecrypter nor SignedSessionDecrypter will prevent replay attacks. Since they only support one-way communication, the receiver gets the data from the sender with no possibility of providing some kind of once-per-transaction salt. Replay prevention has to be handled elsewhere in the protocol (by, for example, asking the sender to create a unique ID and having the receiver store the IDs for comparison.)Well I'd really like to know, what the intended purpose of the nonce is. It's used in the signing, but is it to keep signed data from one session from being verified in a different session? The MAC is going to do that too. Maybe the design of this api is just ignoring the fact that there is a MAC? It seems pretty wasteful, but I guess i can understand that. I just want to make sure I have a clear understanding, so i can convey appropriately in the API.You've moved beyond the limits of what I know - but my suspicion is that this would provide some protection against attacks on the sender's signing key (particularly chosen-plaintext attacks ) by the recipient.