Ben Harris wrote:
The obvious approach is that it effectively becomes part of the nonce. To avoid too much wheel-reinvention, I'd make the nonce the same as the counter used by newmodes, so you could extract the sequence number by: seq(pkt) = nonce(pkt) - nonce(NEWKEYS) + seq(NEWKEYS) (where seq(x) is the sequence number of packet x, nonce(x) is the nonce of packet x (as an integer), and NEWKEYS is the SSH_MSG_NEWKEYS packet that started the use of this key. nonce(NEWKEYS) is the IV generated by the KEX algorithm.)
I'm still not entirely sure that this is safe, or that all authenticated-encryption modes have this kind of nonce, but then I'm also not sure they all have the facility to MAC data without also encrypting them.
I'd say that is not a good idea. The best way is to use random per packet nonces sent explicitly by the sender, and process the sequence number as implicit unencrypted header data. This operation is supported by Helix, CCM and EAX. (OCB doesn't support processing of unencrypted header data, but is designed for nonces that are sequence numbers).
I am not sure exactly how you would implement your solution, but there are two things to keep in mind:
* There are differential attacks against Helix that exploit repeated nonces. Given the nature of differential attacks and how the nonce is processed by Helix, I guess the only safe way to prevent them would be to use independently random nonces. Simply incrementing the nonce by one for each packet would result in nonces with a pair-wise low hamming difference. That gives me chills rather than a warm fuzzy feeling.
* One trivial method of making the nonces independent and still mix in the sequence number would unfortunately not provide protection against replay attacks. This would happen if you e.g. used the formula:
nonce(pkt) = nonce(NEWKEYS) + seq(pkt) - seq(NEWKEYS) + sentnonce(pkt)(where nonce(pkt) is the effective nonce fed into the algorithm by the implementation, and sentnonce is a random value generated by the sender and prefixed to the packet that is sent to the other peer.) The problem with this is that an active attacker can resend packets simply by modifying sentnonce(X) in accordance with the formula to make the packet pass as having any other sequence number.
-- Henrick Hellström www.streamsec.com