Re: [Cryptography] RSA equivalent key length/strength
Hi, On 09/23/2013 10:47 AM, Peter Gutmann wrote: >> I'm inclined to agree with you, but you might be interested/horrified in the >> "1024 bits is enough for anyone" debate currently unfolding on the TLS list: > > That's rather misrepresenting the situation. It's a debate between two > groups, the security practitioners, "we'd like a PFS solution as soon as we > can, and given currently-deployed infrastructure DH-1024 seems to be the best > bet", and the theoreticians, "only a theoretically perfect solution is > acceptable, even if it takes us forever to get it". > > (You can guess from that which side I'm on). Are you talking about the BCP? Then what you say is not true either. 1) General consensus seems to be that recommending DHE-2048 is not a good idea in the BCP, because it will not be available now, nor in short to mid-range time. Voices that utter different opinions are currently a minority; the BCP authors are not among them. 2) Consequently, the BCP effort is currently on deciding whether a ECC variant of DHE or DHE-1024 should be the recommendation. The factions seem to be split about equally: Pro DHE-1024: * Some say not enough systems provide ECDHE to recommend it, and thus DHE1024 should be the primary recommendation. * Some say ECDHE is not trustworthy yet due to implementation difficulties and/or NSA involvement. Pro ECDHE: * Others say Chrome and Firefox will soon, or already do, support ECDHE it. That would leave only the Windows users on IE, and we know that Windows 8.1 will support it. * The same people acknowledge the "trustworthy" argument. The question is whether it weighs heavily enough. That seems to be a more accurate description as I understand it from reading the list. Myself, I am currently still undecided on the issue but tend slightly towards ECDHE for now -- with any luck, the BCP won't be ready until we have some more data on the issue. Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
Hi, >> BTW, I do not really agree with your argument it should be done via TLS >> extension. > > It's done that way based on discussions on (and mostly off) the TLS list by > various implementers, that was the one that caused the least dissent. I've followed that list for a while. What I find weird is that there should be much dissent at all. This is about increasing security based on adding quite well-understood mechanisms. What's to be so opposed to there? Does adding some ciphersuites really require an extension, maybe even on the Standards Track? I shouldn't think so, looking at the RFCs that already do this, e.g. RFC 5289 for AES-GCM. Just go for an Informational. FWIW, even HTTPS is Informational. It really boils down to this: how fast do we want to have it? I spoke to one of the TACK devs a little while ago, and he told me they'd go for the IETF, too, but their focus was really on getting the code out and see an effect before that. The same seems to be true for CT - judging by their commit frequency in the past weeks, they have similar goals. I don't think it hurts to let users and operators vote with their feet here. Ralph ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
Hi, On 09/07/2013 12:50 AM, Peter Gutmann wrote: >> But for right now, what options do we have that are actually implemented >> somewhere? Take SSL. CBC mode has come under pressure for SSL (CRIME, BEAST, >> etc.), and I don't see any move towards TLS > 1.0. > > http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-02 fixes all of > these, I just can't get any traction on it from the TLS WG chairs. Maybe Exactly, precious little movement on that front. Sadly. BTW, I do not really agree with your argument it should be done via TLS extension. I think faster progress could be made by simply introducing new allowed cipher suites and letting the servers advertise them and client accept them - this possibly means bypassing IETF entirely. Or, to keep them in, do it in TLS 1.3. But do it fast, before people start using TLS 1.2. I don't really see the explosion of cipher suite sets you give as a motivation - e.g. in SSH, where really no-one seems to use the standards, we have a total of 144 or so cipher suites found in our scans. Yet the thing works, because clients will just ignore the weird ones. It should be possible in SSL, too, unless openssl/gnutls/nss barfs at an unexpected suite name - but I don't think so. Ralph ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
Hi, >>> It would be good to see them abandon RC4 of course, and soon. >> >> In favour of what, exactly? We're out of good ciphersuites. > > I thought AES was okay for TLS 1.2? Isn't the issue simply that > Firefox etc. still use TLS 1.0? Note that this was a TLS 1.2 > connection. Firefox has added TLS 1.2 two or three weeks ago, and TLS 1.2 does indeed protect against BEAST, CRIME, Lucky 13 (but not against BREACH, I recall). However, my guess would be that too many Apaches out there are linked to older openssl versions that do not yet support TLS 1.1 or TLS 1.2. I have found this a good write-up: https://www.isecpartners.com/media/106031/ssl_attacks_survey.pdf Ralph ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
Hi, > Same here. AES is, as far as we know, pretty secure, so any problems are > going to arise in how AES is used. AES-CBC wrapped in HMAC is about as solid > as you can get. AES-GCM is a design or coding accident waiting to happen. But for right now, what options do we have that are actually implemented somewhere? Take SSL. CBC mode has come under pressure for SSL (CRIME, BEAST, etc.), and I don't see any move towards TLS > 1.0. RC4 was good enough for a while, but with djb's new work - it's just waiting to be improved and made practical by someone. FWIW, we still use RC4 on our servers, but I'd be happy to see something else that is practical. Of course, the above attacks are probably not one of your worries when you're up against the NSA - your own system is probably much more endangered. Ralph ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
Hi, >> There is a host of older literature, too - P2P research, however, has become >> a cold topic. Although I expect that it will see a revival in the face of >> surveillance. > > For people who are interested, the list I have (for a year or two back) is: [list] I would like to add the following: R5n: Randomized recursive routing for restricted-route networks NS Evans, C Grothoff Network and System Security (NSS) 2011 Routing in the dark: Pitch black NS Evans, C GauthierDickey, C Grothoff Computer Security Applications Conference, 2007. ACSAC 2007 Exploiting KAD: possible uses and misuses M Steiner, T En-Najjary, EW Biersack ACM SIGCOMM Computer Communication Review 37 (5), 65-70 A global view of kad M Steiner, T En-Najjary, EW Biersack Proceedings of the 7th ACM SIGCOMM IMC, 2007 Measurements and mitigation of peer-to-peer-based botnets: a case study on storm worm T Holz, M Steiner, F Dahl, E Biersack, F Freiling Proceedings of 1st Usenix Workshop LEET Ralph ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
Hi,
>> Can you rephrase whether you want info about DHT systems that are
>> related to some kind of mix system (e.g. GNUnet), or whether you
>> simply want to know about common DHT systems. If the latter, what
>> kind of attacks are you after? Eclipse?
>
> My knowledge of the field is pretty spotty in general as I've never
> paid much attention up until now -- mostly I know about how people
> have built DHTs in non-hostile environments. I'm close enough to
> starting from scratch that I don't know yet what I don't know.
OK, so I'll just add to what's been written so far.
* Most DHTs are indeed intended for a non-hostile environment and allow
users to freely place information in the DHT. This means that data items
can be easily eclipsed from the network by abusing the DHT's principle
of storing an item on the node with the ID that is closest to the item's
own ID. Most concepts support replica.
* The only DHT type that really has seen wide deployment seems to be
Kademlia, most notably in aMule/eMule and some bot networks. Steiner et
al. showed by example that Eclipse attacks against data items are easy
("Conducting and optimizing Eclipse attacks in the Kad P2P network").
* The aMule developers reacted to that attack by restricting routing
tables. Kohen/Leske et al. showed that this can be easily circumvented
by introducing chains of attackers that cooperate in a particular
fashion to redirect queries and let Kad run into a timeout.
* We have been active in Kad research for a little while, too. We found
that while Eclipse attacks against data items are easy, they are much
much harder against active nodes. I.e. Kad is designed to keep
long-running nodes as long in the routing tables as possible, and to
spread this knowledge widely in the network. This makes it very hard for
an attacker to reroute traffic intended for a victim. However, given a
very strong attacker (1000s of nodes), this should become possible
again. It is one of the disruptive DoS methods.
* The most interesting work that I know of is GNUnet: www.gnunet.org.
They employ a DHT called R5N that combines recursive Kad-style routing
with an initial random walk to evade the above attacker. GNUnet's
problem is that there are not enough developers to get the network to a
reasonable size, but the underlying technology is interesting. GNUnet
also has a SDSI/SPKI-style DNS replacement called GADS. Christian
Grothoff is the main developer and also at TUM (that's how I know him) -
he recently gave a talk on PRISM and GNUnet:
https://www.gnunet.org/internetistschuld
There is a host of older literature, too - P2P research, however, has
become a cold topic. Although I expect that it will see a revival in the
face of surveillance.
Ralph
--
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
On 08/25/2013 09:12 PM, Perry E. Metzger wrote: > For some research on communications privacy I'm doing at the moment, > I'm interested in learning about the state of the art of DHT systems > and mix network systems. I'd like to know both which systems are Can you rephrase whether you want info about DHT systems that are related to some kind of mix system (e.g. GNUnet), or whether you simply want to know about common DHT systems. If the latter, what kind of attacks are you after? Eclipse? Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: A mighty fortress is our PKI
Hi, > Eckersley's and Burns' presentation at Defcon (coming right up) will present > their findings from a global survey of certs presented by hosts listening on > port 443. Their results are disturbing. Have these results already been published somewhere, or do you maybe even have a URL? Ralph - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Question w.r.t. AES-CBC IV
Dear all, A colleague dropped in yesterday and confronted me with the following. He wanted to scrape off some additional bits when using AES-CBC because the messages in his concept are very short (a few hundred bit). So he was thinking about a variant of AES-CBC, where he uses just 32 (random) bits as a source for the IV. These are encrypted with AES and then used as the actual IV to feed into the CBC. As a result, he does not need to send a 128 bit IV to the receiver but just the 32 bit. His argument was that AES basically is used as an expansion function for the IV here, with the added benefit of encryption. On the whole, this should not weaken AES-CBC. Although he was not sure if it actually would strengthen it. While I am prepared to buy this argument (I am not a cryptographer...), I still felt that the argument might not be complete. After all, 32 bits don't provide much randomness, and I wasn't sure if this, overall, would not lead to more structure in the ciphercode - which might in turn give an attacker more clues with respect to the key. Are there any opinions on this? Regards, Ralph - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
