I replied to Tero privately, then realized that I was
not the only recipient of his email. So here's a copy
for everyone's reference.
Alex
Tero Kivinen wrote:
>> Travis H. writes:
>>
>
>>>>http://www.hamachi.cc/
security
>>>>
>>>>Based on a cursory look over this, I'm
impressed by both the level of
>>>>detail and the level of security apparently
afforded. Too bad I can't
>>>>see the source code.
>
>>
>>
>> I can see couple of problems in the system. Firstly
it seems it uses
>> same key for both directions for the encryption and
for
>> authentication, i.e. the KEYMAT is only split to Ke
and Ka keys, which
>> are used for encryption and authentication. In
general using same keys
>> for different directions is bad.
The description on a page was not updated properly. Recent
clients
use per-direction keys after they complete P2P KE.
>> 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.
>> Also it seems that the identity itself
>> is not authenticated at all, as it (or it's MACed
form) is not
>> included in the signature.
It is not.
>> There might be (I am not sure whether AUTH
>> packet is encrypted and MACed) a MAC over it, but
the MAC key is not
>> yet authenticated as it is generated from the
anonymous
>> Diffie-Hellman. That might give it some protection,
but I am not sure
>> if that is enough.
A protection against what kind of attack ?
Identity is used to specify which public key the client
wants
to be authenticated with on the server side. Assuming it is
swapped in transition by a man in the middle, it would still
require an attacker to re-sign authentication hash in the
message.
Assuming he has a private key to do that, he will
effectively
succeed in authenticating under substituted ID. He then will
need to re-sign server's auth hash to complete the attack,
which is not going to happen.
There is an off chance that the attacker might swapped the
identity to one that has the same public key. The chances
of this happening are infinitely small unless an attacker
also has an access to victim's keypair, which becomes a
trivial attack case.
>> 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.
>> The protocol is also tied to use SHA1.
If you are referring to HMAC-SHA1 for authentication hashes,
it
is a part of a crypto suite (protocol revision) spec.
>> In general it would be much better to use standard
protocol, instead
>> of generating your own.
This is the second revision of Hamachi system. First
revision
was using SSL for cli-srv and IKE/ESP for p2p security. It
was
a prototype and it soon become obvious that both SSL and IKE
were overkills for our purposes. We did not need certificate
authentication of SSL, we did not want to run our own auth
protocol over SSL/AnonDH, which would've increased the
number
of packets per login sequence. We didn't need the
flexibility
(ie complexity) of IKE either.
After stripping down IKE (ie removing SA negotiation,
reworking
ID payloads and not doing quick mode), we essentially ended
up
with a protocol that was also fit for securing cli-srv
session.
It was further tweaked and replaced SSL.
I should probably add that I implemented IKE (v1) keying
daemon
from scratch with all bells and wistles (NATT, extended MODP
groups, etc) at some point in the past. Some remnants of it
are still floating around, the library name was libike.
>> Designing security protocols is hard...
Yes, it is. This is why I like it.
------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomo metzdowd.com
|