Re: hamachi p2p vpn nat-friendly protocol details
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 [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
On 2006-02-24, Peter Saint-Andre wrote: > Personally I doubt that anything other than a small percentage of email > will ever be signed, let alone encrypted (heck, most people on this list > don't even sign their mail). That's at least partly because too many mailing lists either reject signed messages out of hand or, worse, have subscribers who use providers that reject signed messages and then spam you with their idiotic bounce messages. Keeping track of which lists allow signed email and which don't is impractical if you subscribe to hundreds of lists, so the simple thing is to tick the "don't sign" box on list messages. In this case, since Peter's message was signed, I know this list allows signatures. So I'll sign this message. But the signature will be of limited utility, as not one of the several email addresses on my signature is a match for the email address I am sending this from. Again, lists being what they are, I use a different address for most lists and my PGP key would become absurd if I added several hundred addresses to it. I personally would prefer to sign every email I send. I'd also prefer to encrypt all non-public messages. I am fully competent in the use of the current technology, but it turns out to be not practical to use. Greg pgp3qLCcQF5wT.pgp Description: PGP signature
Re: NPR : E-Mail Encryption Rare in Everyday Use
>From: Peter Saint-Andre <[EMAIL PROTECTED]> >Sent: Feb 24, 2006 3:18 PM >Subject: Re: NPR : E-Mail Encryption Rare in Everyday Use ... >We could just as well say that "encryption of remote server sessions is >rare in everyday use". It's just that only geeks even do remote server >sessions, so they use SSH instead of telnet. >The thing is that email is in wide use (unlike remote server sessions). >Personally I doubt that anything other than a small percentage of email >will ever be signed, let alone encrypted (heck, most people on this list >don't even sign their mail). I'm certain that only a small percentage of e-mail will ever be signed, so long as the tools to do that are so hard to use, and the value added so small. I find it useful to use encryption all the time on my private data, but virtually never use it for communications, because even among cryptographers the setup hassles are too great, and the value added too small. What we ultimately need is encryption and authentication that are: a. Automatic and transparent. b. Add some value or are bundled with something that does. c. Don't try to tie into the whole horrible set of PKI standards in terms of uniquely identifying each human and bit in the universe, and getting them to sign legally binding messages whose full interpretation requires reading and understanding a 30-page CPS. If email encryption became as transparent as SSL, most e-mail would be encrypted. This would still leave various phishing issues, etc., but eavesdropping and a lot of impersonation and spam and phishing would get much harder. >Peter --John Kelsey - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
While there is merit in arguing how to simplify the mechanics of using public key encryption for sending and receiving email, I cannot agree with this assertion: At 10:44 AM -0800 2/24/06, Ed Gerck wrote: My $0.02: If we want to make email encryption viable (ie, user-level viable) then we should make sure that people who want to read a secure communication should NOT have to do anything before receiving it. Having to publish my key creates sender's hassle too ...to find the key. If an individual wants to receive telephone calls, he has to agree to publish his phone number. For many years, we tacitly agreed that our phone numbers would be published. That a phone number was public information wasn't perceived as a problem. But as the number of junk calls increases, the number of people who opt out of phone directories increases. Today, more individuals decide that having a public phone number is a problem. In this regard, public keys are just like cell phone numbers. How many people know your cell phone number? How did they get it? You can't get a cell phone number from directory assistance. So if you want someone to be able to call you on your cell phone, you have to give them the "key" to your cell phone. If you want someone to send you encrypted email, you have to give them your public key. It's the same thing. Yet cell phones seem to be viable. -- john noerenberg -- It took long enough in all conscience for realization to come that the externals of civilization - technology, industry, commerce, and so on - also require a common basis of intellectual honesty and morality. -- Herman Hesse, The Glass Bead Game, 1943 -- - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
At 02:59 PM 2/24/2006 +, Ben Laurie wrote: Ed Gerck wrote: We have keyservers for this (my chosen technology was PGP). If you liken their use to looking up an address in an address book, this isn't hard for users to grasp. I used PGP (Enterprise edition?) to encrypt my work emails to a distributed set of members last year. We all had each other's public keys (about a dozen or so). What I really hated about it was that when [EMAIL PROTECTED] sent me an email often I couldn't decrypt it. Why? Because his firm's email server decided to put in the FROM field "[EMAIL PROTECTED]". Since it didn't match the email name in his X.509 certificate's DN it wouldn't decrypt the S/MIME attachment. This also caused problems with replying to his email. It took us hours, with several experimental emails sent back and forth, to figure out the root of the problem. No wonder PKI has died commercially and encrypted email is on the endangered species list. - Alex -- - Alex Alten - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
At 06:09 PM 2/24/2006 +0100, Ian G wrote: Steven M. Bellovin wrote: Certainly, usability is an issue. It hasn't been solved because there's no market for it here; far too few people care about email encryption. Usability is the issue. If I look over onto my skype window, it says there are 5 million or so users right now. It did that without any of the hullabaloo of the other systems, and still manages to encrypt my comms. By some measures it is the most successful crypto system ever. Actually the usability issue has been solved elsewhere too. We did it over at TriStrata before the firm crashed in 1998. We allowed the system security officer to select the default cipher to use in sending emails (DES, 3DES, Blowfish, RC4, etc.). The receiver could use any cipher for decrypting incoming email. A sys admin installed some filter software into the email client, and except for an initial login dialog (and we even simplified that by hooking the OS login dialog), the user never had to do anything further. The local auth keys that he received during enrollment were encrypted with his password on a small floppy disk, or could be installed on the hard drive automatically. Last I heard (early 2005) one system was operational over in the nuclear engineering department at Ohio State (for DOE work?). Of course one old system rack in the dusty corner of a school building does not a market make. - Alex -- - Alex Alten - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: hamachi p2p vpn nat-friendly protocol details
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]
Re: NPR : E-Mail Encryption Rare in Everyday Use
-- Ben Laurie wrote: > > but if you want it to be encrypted to you, then you need to > > publish a key. Ed Gerck wrote: > This IS one of the sticky points ;-) If postal mail would work this > way, you'd have to ask me to send you an envelope before you can > send me mail. This is counter-intuitive to users. Public key should be part of signature. > Your next questions could well be how do you know my key is really > mine... If key is part of signature, you know it really belongs to the person who posted the item to which you are replying - and sometimes that is the thing that you really want to know. Of course you do not know that the person to which you are replying is really the person he represents himself as being - is he really the fraud control officer for your bank? But presumably you are interacting with the bank through its website, so you, or rather your software, should damn well know the bank's public key, and the fraud control officer's signature should have a certificate by the bank attesting his relationship to the bank. > how do you know it was not revoked It should be checked every time you logon to the bank, and every time you logon, instead of telling the site your password, you proceed with a zero knowledge proof where both parties prove knowledge of the password without revealing the password. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG L4p0k6+mzp2x2QNOdALduMQfwAIXYrsJ3cVYYK4Q 4iEeX76ichaV+J6eVImNtWEoGzvMmAHKNHHix+chD - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
Peter Saint-Andre wrote: > Ian G wrote: > >> To get people to do something they will say "no" >> to, we have to give them a freebie, and tie it >> to the unpleasantry. E.g., in SSH, we get a better >> telnet, and there is only the encrypted version. > > We could just as well say that "encryption of remote server sessions is > rare in everyday use". It's just that only geeks even do remote server > sessions, so they use SSH instead of telnet. > > The thing is that email is in wide use (unlike remote server sessions). > Personally I doubt that anything other than a small percentage of email > will ever be signed, let alone encrypted (heck, most people on this list > don't even sign their mail). I don't sign mail not because I can't be bothered, but because it is my policy to not sign mail. If I signed it, it would be substantially harder to deny I wrote it. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
Ed Gerck wrote: > Ben Laurie wrote: >> Really? I just write "Ed Gerck" on an envelope and it gets to you? I >> doubt it. Presumably I have to do all sorts of hard and user-unfriendly >> things to find out and verify your address. > > Perhaps I wasn't clear -- with postal mail you just write my name and > address > in YOUR envelope and it gets to me. With PGP and PKI you have to ask for MY > "envelope" first; further, MY public-key creates the secure envelope > that you > now need to trust with YOUR secret... I totally don't buy this distinction - in order to write to you with postal mail, I first have to ask you for your address. Apart from content of the blob handed over, the two transactions are identical. >> If you handled your keys properly I would not need to ask you for >> anything. > > My $0.02: If we want to make email encryption viable (ie, user-level > viable) > then we should make sure that people who want to read a secure > communication > should NOT have to do anything before receiving it. Having to publish my > key > creates sender's hassle too ...to find the key. So you think people can use the post to write to you without you publishing your address? > BTW, users should NOT be trusted to handle keys, much less to handle them > properly. This is what the users themselves are saying and exemplifying in > 15 years of experiments. I think users are perfectly capable of handling keys. The problem they have is in choosing operating systems that are equal to the task. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
Peter Saint-Andre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian G wrote: To get people to do something they will say "no" to, we have to give them a freebie, and tie it to the unpleasantry. E.g., in SSH, we get a better telnet, and there is only the encrypted version. We could just as well say that "encryption of remote server sessions is rare in everyday use". It's just that only geeks even do remote server sessions, so they use SSH instead of telnet. The thing is that email is in wide use (unlike remote server sessions). Well! Within the context of any given application, we can learn lessons. Just because SSH is only used by geeks is meaningless, really, we need to ground that criticism in something that relates it to other areas. The fact is that SSH came in with a solution and beat the other guy - Telnet secured over SSL. It wasn't the crypto that did this, it was the key management, plain and simple. Telnet was in widespread use - but was incapable of making the jump to secure. Just like email. So if the SSH example were illuminating, we would predict that some completely different *non-compatible* app would replace email. Hence, IM/chat, Skype, TLS experiments at Jabber, as well as the OpenPGP attempts. There are important lessons to be learnt in the rise of IM over email. Email is held back by its standardisation, chat seems to overcome spam quite nicely. Email is hard to get encrypted, but it didn't stop Skype from doing encryped IMs "easily." Phishing is possible over chat, but has also been relatively easy to address - because the system owners have incentives and can adjust. The competition between the IM systems is what is driving the security forward. As there is no competition in the email world, at least at the level of the basic protocol and standard, there is no way for the security to move forward. iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: hamachi p2p vpn nat-friendly protocol details
Travis H. wrote: > On 2/24/06, Alex Pankratov <[EMAIL PROTECTED]> wrote: > >>Tero Kivinen wrote: [snip] 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. Nonces and DH exponents are serialized using PER-style ASN.1 encoding. So the whole concatenation is unambigious. > 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. Just to be clear, Hamachi tunnels VPN/P2P traffic over UDP. TCP is used for client-server session only. VPN over TCP is bad for two reasons. One you listed, and another is that it becomes trivial to DoS this kind of VPN. TCP packets are not authenticated (unless MD5/BGP extension is used, which is unlikely), so the state of VPN transport layer and consequently the state of a tunnel can be altered by 3rd party. That's why SSL VPNs make very little sense in non-proxied setups and that's why (I'd guess) OpenVPN 'tweaked' SSL to run over UDP instead. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
Ben Laurie wrote:
I totally don't buy this distinction - in order to write to you with
postal mail, I first have to ask you for your address.
We all agree that having to use name and address are NOT the problem,
for email or postal mail. Both can also deliver a letter just with
the address ("CURRENT RESIDENT" junk mail, for example).
The problem is that pesky public-key. A public-key such as
[2. application/pgp-keys]...
is N O T user-friendly.
Arguments that people give each other their cell phone numbers, for example,
and even though there isn't a cell phone directory people use cell phones
well, also forget the user's point of view when comparing a phone number with
a public-key.
Finally, the properties of MY public-key will directly affect the
confidentiality
properties of YOUR envelope. For example, if (on purpose or by force) my
public-key
enables a covert channel (eg, weak key, key escrow, shared private key), YOUR
envelope is compromised from the start and you have no way of knowing it. This
is
quite different from an address, which single purpose is to route the
communication.
That's I said the postal analogue of the public-key is the envelope.
Ed Gerck wrote:
My $0.02: If we want to make email encryption viable (ie, user-level
viable)
then we should make sure that people who want to read a secure
communication
should NOT have to do anything before receiving it. Having to publish my
key
creates sender's hassle too ...to find the key.
So you think people can use the post to write to you without you
publishing your address?
I get junk mail all the time at two different postal addresses, without ever
having published either of them. Again, addresses and names are user friendly
(for better or for worse) while public-keys are not -- in addition to their
different security roles (see above).
Ed Gerck wrote:
BTW, users should NOT be trusted to handle keys, much less to handle them
properly. This is what the users themselves are saying and exemplifying in
15 years of experiments.
I think users are perfectly capable of handling keys. The problem they
have is in choosing operating systems that are equal to the task.
That's another notorious area where users can't be trusted -- and that's why
companies lock down their OSes -- or, should a company really allow each user
to choose their desired OS? Apart from compatibility issues, which also do
not allow users to freely choose even the OS in their homes ("Junior wants
to play his games too" scenario).
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
Victor Duchovni wrote: > On Fri, Feb 24, 2006 at 01:44:14PM +, Ben Laurie wrote: > >> Ed Gerck wrote: >>> Paul, >>> >>> Usability should by now be recognized as the key issue for security - >>> namely, if users can't use it, it doesn't actually work. >>> >>> And what I heard in the story is that even savvy users such as Phil Z >>> (who'd have no problem with key management) don't use it often. >>> >>> BTW, just to show that usability is king, could you please send me an >>> encrypted email -- I even let you choose any secure method that you want. >> Sure I can, but if you want it to be encrypted to you, then you need to >> publish a key. > > More strongly, if we've never met, and you are not in the habit of > routinely signing email, thereby tying a key to your e-persona, it > makes no sense to speak of *secure* communication to *you*. Which "you" > would that be, the one who sent me all those exciting zip files of W32 > executables, or the one I think is posting to this list? > > The only identity you (who hypothetically do not garnish each message > with a signature) have is your mailbox. I can bootstrap that (with > questionable initial security) to a key via a "private" unencrypted > email message, and over a time as the key is consistently used grow to > associate the key with an on-line persona. Don't forget that the ability to decrypt is just as good as a signature to prove association of the key. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Cracking remaining Enigma messages
There is a project out there to crack a few of the remaining Enigma intercepts from the second world war that were never cracked the first time around... http://www.bytereef.org.nyud.net:8080/m4_project.html -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
