On 2/24/06, Alex Pankratov <[EMAIL PROTECTED]> wrote: > Tero Kivinen wrote: > >> Secondly I cannot find where it > >> authenticates the crypto suite used at all (it is not included in the > >> signature of the AUTH message). > > Crypto suite is essentially just a protocol number. It requires > no authentication. If the server side responds with HELO.OK, it > means that it can comprehend specified protocol revision. Similar > to what happens during the SSH handshake.
In SSL, the lack of authentication of the cryptosuite could be used to convince a v3 client that it is communicating with a v2 server, and the v3 server that it is communicating with a v2 client, causing them to communicate using SSL v2, which is called the "version rollback attack". This is not relevant to the hamachi protocol because there is no negotiation. Nevertheless, authenticating the previous plaintext fields once a secure channel is established is considered good form. In Schneier's "Practical Cryptography", he suggests computing the MAC over the entire history of sent messages, which ensures that any tampering is detected at the next MAC. This is eventually what was done in SSLv3, for reasons Tero alluded to and which are successfully thwarted for the reasons you describe. > >> The protocol description is missing some details, so cannot say > >> anything about them (things like what is the format of Ni, Nr, Gi, Gr > >> when sent over wire and when put to the signatures etc, are the Gi, Gr > >> always the lenght of modulus (2048 bits) etc). > > What would you like to know exactly ? The page was not meant to > be a bit-level description of messages, merely a description of > the security framework. Presumably he wants to make sure that the messages like the following have an unambiguous interpretation: AUTH Identity Signature(Ni | Nr | Gi | Gr, Kpri_cli) Merely concatenating them is insufficient unless all but one have a fixed length. I think a terse "unambiguous representation" rationale is the whole reason for ASN.1, although it seems awfully complex for such a simple goal. I sort of wonder at the utility of a TCP implementation of the p2p VPN... tunnelling TCP over TCP is well known to be a Bad Thing with regard to interaction of the TCP timeouts. Aside: Can anyone tell me why the constants used in ipad and opad for HMAC were chosen? If they're not arbitrary, I'd like to know the rationale behind them. -- Security Guru for Hire http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]