Re: [cryptography] [Cryptography] TLS2
On Mon, Sep 30, 2013 at 11:49:49AM +0300, ianG wrote: On 30/09/13 11:02 AM, Adam Back wrote: no ASN.1, and no X.509 [...], encrypt and then MAC only, no non-forward secret ciphersuites, no baked in key length limits [...] support soft-hosting [...] Add TOFO for self-signed keys. Personally, I'd do it over UDP (and swing for an IP allocation). I think lack of soft-hosting support in TLS was a mistake - its another reason not to turn on SSL (IPv4 addresses are scarce and can only host one SSL domain per IP#, that means it costs more, or a small hosting company can only host a limited number of domains, and so has to charge more for SSL): and I dont see why its a cost worth avoiding to include the domain in the client hello. There's an RFC for how to retrofit softhost support via client-hello into TLS but its not deployed AFAIK. The other approach is to bump up security - ie start with HTTP, then switch to TLS, however that is generally a bad direction as it invites attacks on the unauthenticated destination redirected to. I know there is also another direction to indicate via certification that a domain should be TLS only, but as a friend of mine was saying 10 years ago, its past time to deprecate HTTP in favor of TLS. Both client and server must have a PP key pair. Well clearly passwords are bad and near the end of their life-time with GPU advances, and even amplified password authenticated key exchanges like EKE have a (so far) unavoidable design requirement to have the server store something offline grindable, which could be key stretched, but thats it. PBKDF2 + current GPU or ASIC farms = game over for passwords. However whether its password based or challenge response based, I think we ought to address the phish problem for which actually EKE was after all designed for (in 1992 (EKE) and 1993 (password augmented EKE)). Maybe as its been 20 years we might actually do it. (Seems to be the general rule of thumb for must-use crypto inventions that it takes 20 years until the security software industry even tries). Of course patents ony slow it down. And coincidentally the original AKE patent expired last month. (And I somehow doubt Lucent, the holder, got any licensing revenue worth speaking about between 1993 and now). By pinning the EKE or AKE to the domain, I mean that there should be no MITM that can repurpose a challenge based on phish at telecon.com to telecom.com, because the browser enforces that EKE/AKE challenge reponse includes the domain connected to is combined in a non-malleable way into the response. (EKE/AKE are anyway immune to offline grinding of the exchanged messags.) Clearly you want to tie that also back to the domains TLS auth key, otherwise you just invite DNS exploits which are trivial across ARP poisoning, DNS cache-poisoning, TCP/UDP session hijack etc depending on the network scenario. And the browser vendors need in the case of passwords/AKE to include a secure UI that can not be indistinguishably pasted over by carefully aligned javascript popups. (The other defense with securid and their clones can help prop up AKE/passwords.) Both, used every time to start the session, both sides authenticating each other at the key level. Any question of certificates is kicked out to a higher application layer with key-based identities established. While certs are a complexity it would be nice to avoid, I think that reference to something external and bloated can be a problem, as then like now you pollute an otherwise clean standard (nice simple BNF definition) with something monstrous like ASN.1 and X.500 naming via X.509. Maybe you could profile something like openPGP though (it has its own crappy legacy they're onto v5 key formats by now, and some of the earlier vs have their own problems, eg fingerprint ambiguity arising from ambiguous encoding and other issues, including too many variants, extra mandatory/optional extensions.) Of course the issue with rejecting formats below a certain level is the WoT is shrunk, and anyway the WoT is also not that widely used outside of operational security/crypto industry circes. That second argument may push more towards SSH format keys which are by comparison extremely simple, and are recently talking about introducing simple certification as I recall. Adam ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] TLS2
On 30 September 2013 10:47, Adam Back a...@cypherspace.org wrote: I think lack of soft-hosting support in TLS was a mistake - its another reason not to turn on SSL (IPv4 addresses are scarce and can only host one SSL domain per IP#, that means it costs more, or a small hosting company can only host a limited number of domains, and so has to charge more for SSL): and I dont see why its a cost worth avoiding to include the domain in the client hello. There's an RFC for how to retrofit softhost support via client-hello into TLS but its not deployed AFAIK. Boy, are you out of date: http://en.wikipedia.org/wiki/Server_Name_Indication. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] three crypto lists - why and which
I am not sure if everyone is aware that there is also an unmoderated crypto list, because I see old familiar names posting on the moderated crypto list that I do not see posting on the unmoderated list. The unmoderated list has been running continuously (new posts in every day with no gaps) since mar 2010, with an interesting relatively low noise, and not firehose volume. http://lists.randombit.net/mailman/listinfo/cryptography The actual reason for the creation of that list was Perry's list went through a hiatus when Perry stopped approving/forward posts eg http://www.mail-archive.com/cryptography@metzdowd.com/ originally Nov 2009 - Mar 2010 (I presume the mar 2010 restart was motivated by the creation of randombit list starting in the same month) but more recently sep 2010 to may 2013 gap (minus traffic in aug 2011). http://www.metzdowd.com/pipermail/cryptography/ I have no desire to pry into Perry's personal circumstances as to why this huge gap happened, and he should be thanked for the significant moderation effort he has put into create this low noise environment, but despite that it is bad for cryptography if people's means of technical interaction spuriously stops. Perry mentioned recently that he has now backup moderators, OK so good. There is now also the cypherpunks list which has picked up, and covers a wider mix of topics, censorship resistant technology ideas, forays into ideology etc. Moderation is even lower than randombit but no spam, noise slightly higher but quite reasonable so far. And there is now a domain name that is not al-quaeda.net (seriously? is that even funny?): cpunks.org. https://cpunks.org/pipermail/cypherpunks/ At least I enjoy it and see some familiar names posting last seen decade+ ago. Anyway my reason for posting was threefold: a) make people aware of randombit crypto list, b) rebooted cypherpunks list (*), but c) about how to use randombit (unmoderated) and metzdowd. For my tastes sometimes Perry will cut off a discussion that I thought was just warming up because I wanted to get into the detail, so I tend more prefer the unmoderated list. But its kind of a weird situaton because there are people I want views and comments from who are on the metzdowd list who as far as I know are not on the crypto list, and there's no convenient way to migrate a conversation other than everyone subscribing to both. Cc to both perhaps works somewhat, I do that sometimes though as a general principle it can be annoying when people Cc to too many lists. Anyway thanks for your attention, back to the unmoderated (or moderated) discussion! Adam ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] TLS2
Hi Ben, Boy, are you out of date: http://en.wikipedia.org/wiki/Server_Name_Indication. I am not so sure many servers support it, though. My latest data, unfortunately, is not evaluated yet. But in 2011 the difference between switching on SNI and connecting without it, was pretty meagre across the Alexa range. Granted, many of those hosts may not be VHosts. Does Google have better data on that? 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] TLS2
On 30 September 2013 07:07, Ralph Holz h...@net.in.tum.de wrote: Hi Ben, Boy, are you out of date: http://en.wikipedia.org/wiki/Server_Name_Indication. I am not so sure many servers support it, though. My latest data, unfortunately, is not evaluated yet. But in 2011 the difference between switching on SNI and connecting without it, was pretty meagre across the Alexa range. Granted, many of those hosts may not be VHosts. Does Google have better data on that? I think you're testing that wrong. The major websites run one website at multiple IPs - not multiple websites at a single IP. So connecting with/without SNI will usually get you the same result. You want to test the Alexis 2,000,000 - 3,000,000 sites and see if you get a different result - hit shared hosting sites, where multiple sites run on a single IP. As far as software support, there are a few clients where support isn't there (most notable Java 1.7 and anything on Windows XP), but server support is there.[0] -tom [0] https://en.wikipedia.org/wiki/Server_Name_Indication ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] TLS2
(repost from Crypto with a Kapital C, slightly editted. I think this is more software engineering than crypto). On 28/09/13 20:07 PM, Stephen Farrell wrote: b) is TLS1.3 (hopefully) and maybe some extensions for earlier versions of TLS as well SSL/TLS is a history of fiddling around at the edges. If there is to be any hope, start again. Remember, we know so much more now. Call it TLS2 if you want. Start with a completely radical high-level set of requirements. Why not do the requirements, then ask for competing proposals? Choose the one. There are a dozen teams here who could produce it. It worked for NIST, and committees didn't work for anyone. A competition for TLS2 would bring out the best and leave the bureaurats fuming and powerless. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] TLS2
Hi, I am not so sure many servers support it, though. My latest data, unfortunately, is not evaluated yet. But in 2011 the difference between switching on SNI and connecting without it, was pretty meagre across the Alexa range. Granted, many of those hosts may not be VHosts. Does Google have better data on that? I think you're testing that wrong. The major websites run one website at multiple IPs - not multiple websites at a single IP. So connecting with/without SNI will usually get you the same result. To clarify: we did not hunt SNI-enabled sites. We were after cases where a server on the Alexa lists shows the default certificate for another site, but will show the correct one if SNI is enabled. We thus did two scans back then, one with and one without SNI enabled, and determined whether we saw different certificates for some domains. In the setup you describe, we'd fully expect the same certs -- and I agree it seems to be the much more prevailing setup. You want to test the Alexis 2,000,000 - 3,000,000 sites and see if you get a different result - hit shared hosting sites, where multiple sites run on a single IP. Ideally, I'd combine an IP scan with DNS information from zone files (which we have, but I don't have the time to do it). [0] https://en.wikipedia.org/wiki/Server_Name_Indication Yes, but our scans back then did not determine deployed server versions. 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] TLS2
On 30/09/13 10:47, Adam Back wrote: Well clearly passwords are bad and near the end of their life-time with GPU advances, and even amplified password authenticated key exchanges like EKE have a (so far) unavoidable design requirement to have the server store something offline grindable, which could be key stretched, but thats it. PBKDF2 + current GPU or ASIC farms = game over for passwords. what about stronger pwd-based key exchange like SRP and JPAKE? Passwords don't scale up and are very inconvenient, but are you sure your argument PBKDF2 + current GPU or ASIC farms = game over for passwords really holds? what about scrypt? And theoretically, you can always increase the number of rounds in the hash... I refer to this link too: http://www.lightbluetouchpaper.org/2013/01/17/moores-law-wont-kill-passwords/ Looking forward to ur comments. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] PBKDF2 + current GPU or ASIC farms = game over for passwords (Re: TLS2)
On Mon, Sep 30, 2013 at 02:34:27PM +0100, Wasa wrote: On 30/09/13 10:47, Adam Back wrote: Well clearly passwords are bad and near the end of their life-time with GPU advances, and even amplified password authenticated key exchanges like EKE have a (so far) unavoidable design requirement to have the server store something offline grindable, which could be key stretched, but thats it. PBKDF2 + current GPU or ASIC farms = game over for passwords. what about stronger pwd-based key exchange like SRP and JPAKE? what I mean there is a so far unavoidable aspect of the AKE design pattern is that the server holds verifier v = PBKDF2(count,salt,password), so the server if hostile, or of even more concern an attacker who steals the whole database of user verifiers from the server can grind passwords against it. There is a new such server hashed password db attack disclosed or hushed up every few weeks. Passwords don't scale up and are very inconvenient, but are you sure your argument PBKDF2 + current GPU or ASIC farms = game over for passwords really holds? what about scrypt? And theoretically, you can always increase the number of rounds in the hash... I refer to this link too: http://www.lightbluetouchpaper.org/2013/01/17/moores-law-wont-kill-passwords/ You know GPUs are pretty good at computing scrypt. Eg look at litecoin (bitcoin with hashcash mining changed to scrypt mining, people use GPUs for ~10x speed up over CPUs). Litecoin was originally proposed as I understood it to be more efficient on CPU than GPU, so that people could CPU mine and GPU mine without competing for resources, but they chose a 128kB memory consumption parameter, and it transpired that GPUs can compute on that memory size fine (any decent GPU has 1GB of ram and a quite nice cacheing hierarchy). Clearly its desirable to have modest memory usage on a CPU or if it fill L3 cache the CPU will slow down significantly for other applications. Even 128kB is going to fill L1 and half of L2 which has to cost generic performance. Anyway in the bitcoin context that coincidentally was fine because then FPGAs ASICs became the only way to profitably mine hashcash based bitcoin, and so GPUs were freed up to mine scrypt based litecoin. Also for bitcoin purposes higher memory scrypt parameters increase the validation phase (where all full nodes check all hashes and signatures, a double SHA256 is a lot faster than a scrypt at even 128KB, changing that to eg 128MB will only make it worse. Also the PBKDF2 / scrypt happens on the client side - how do you think your ARM powered smart phone will compare to a 9x 4096 core GPU monster. Not well :) So yes I stand by that. One could use higher memory scrypt parameters, and so the claim goes with memory bound functions that memory IO is less dissimilar between classes of machines than CPU speed (smartphone vs GPU). However you have to bear in mind also that scrypt actually has CPU memory tradeoffs, known about and acknowledged by its designer. I believe its realtively easy to construct a tweaked scrypt that doesnt have this problem. Also for the bitcoin/litecoin side of things I heard a rumor that there were people working on a litecoin ASIC. Bitcoin FTW in terms of proving the vulnerability of crypto password focussed KDFs to ASIC hardware. The scrypt time memory tradeoff issue maybe useful for efficient scrypt ASIC design. But there is a caveat which is the client/server imbalance is related to the difference in CPU power between mobile devices and server GPU or ASIC farms. While it is true that moore's law seems to have slowed down in terms of clock rates and serial performance the number of cores and memory architectures are still moving forward, and for ASICs density, clock rates and energy efficiency are increasing, and thats what counts for password cracking. But yes the longer term picture depends on the trend of the ratio between server GPU/ASIC performance vs mobile CPU. Another factor also is the mobiles are more elastic (variable clock, more cores) but to get full perf you end up with power drain and people dont thank you for draining their phone battery. It is possible for ARM eg to include an scrypt or a new ASIC unfriendly password KDF on the die perhaps if there was enough interest. The ready availability of cloud is another dynamic where you dont even have to own the GPU farm to use it. You can rent it by the hour or even minute, or use paid password cracking services (with some disclaimer that it better be for an account owned by you). Anyway and all that because we are seemingly alergic to using client side keys which kill the password problem dead. For people with smart phones to hand all the time eg something like oneid.com (*) can avoid passwords (split keys between smart phone and server, nothing on server to grind, even stolen smart phone cant have its encrypted key store offline ground to recover encrypted private keys (they are also split so you need
Re: [cryptography] Allergy for client certificates
On 09/30/13 17:43, Adam Back wrote: Anyway and all that because we are seemingly alergic to using client side keys which kill the password problem dead. Hi Adam, I wondered about that 'allergy' myself. I have some ideas about that and I'm curious to learn about other. Here are mine: 1. The long standing belief is that client systems are untrustworthy. Any malware will go after the client certificates. So without proper sandboxing, capability-security and other partitioning mechanisms, the user is toast. The most popular consumer-OS was (is?) also the most leaky. Where was The Hurd when we needed it? Why did people fall for Unix when Multics was so much better? 2. It's easier to change a password in a database than to talk the user through creating an submitting a new pub/priv key pair. 3. The crypto-programs were too diffucult to use. Requiring end users to make trust decisions about entities they never heard of. Who is Verisign and why should I trust them 4. Client certificates from the big CA-peddlers are akin digital passports, eliminating all non-repudiation. Ie, a privacy problem. 5. Only recently, computers have become powerful enough to encrypt everything, all the time. Now we can afford to burn cpu cycles on encryption without getting usability to suffer. Guido. signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PBKDF2 + current GPU or ASIC farms = game over for passwords (Re: TLS2)
On 30/09/13 16:43, Adam Back wrote: On Mon, Sep 30, 2013 at 02:34:27PM +0100, Wasa wrote: On 30/09/13 10:47, Adam Back wrote: Well clearly passwords are bad and near the end of their life-time with GPU advances, and even amplified password authenticated key exchanges like EKE have a (so far) unavoidable design requirement to have the server store something offline grindable, which could be key stretched, but thats it. PBKDF2 + current GPU or ASIC farms = game over for passwords. what about stronger pwd-based key exchange like SRP and JPAKE? what I mean there is a so far unavoidable aspect of the AKE design pattern is that the server holds verifier v = PBKDF2(count,salt,password), so the server if hostile, or of even more concern an attacker who steals the whole database of user verifiers from the server can grind passwords against it. There is a new such server hashed password db attack disclosed or hushed up every few weeks. Passwords don't scale up and are very inconvenient, but are you sure your argument PBKDF2 + current GPU or ASIC farms = game over for passwords really holds? what about scrypt? And theoretically, you can always increase the number of rounds in the hash... I refer to this link too: http://www.lightbluetouchpaper.org/2013/01/17/moores-law-wont-kill-passwords/ You know GPUs are pretty good at computing scrypt. Eg look at litecoin (bitcoin with hashcash mining changed to scrypt mining, people use GPUs for ~10x speed up over CPUs). Litecoin was originally proposed as I understood it to be more efficient on CPU than GPU, so that people could CPU mine and GPU mine without competing for resources, but they chose a 128kB memory consumption parameter, and it transpired that GPUs can compute on that memory size fine (any decent GPU has 1GB of ram and a quite nice cacheing hierarchy). Clearly its desirable to have modest memory usage on a CPU or if it fill L3 cache the CPU will slow down significantly for other applications. depends on the context i guess. if you are using a smartphone to log-in your banking app, it does not matter so much if you slow down other _background_ apps. Even 128kB is going to fill L1 and half of L2 which has to cost generic performance. Anyway in the bitcoin context that coincidentally was fine because then FPGAs ASICs became the only way to profitably mine hashcash based bitcoin, and so GPUs were freed up to mine scrypt based litecoin. Also for bitcoin purposes higher memory scrypt parameters increase the validation phase (where all full nodes check all hashes and signatures, a double SHA256 is a lot faster than a scrypt at even 128KB, changing that to eg 128MB will only make it worse. Also the PBKDF2 / scrypt happens on the client side - how do you think your ARM powered smart phone will compare to a 9x 4096 core GPU monster. Not well :) i had this in the back of mind when I replied to ur email; so I tend to be on ur side here How much would it help to delegate PBKDF2 / scrypt to smartphone GPU to break this asymmetry? since SRP and JPAKE use exponent_modulo sort of computation rather than a hash, any idea how this impacts attackers? how well can you paralellize a dictionary brute force for DL problem? I'm not expert so glad to hear about it. So yes I stand by that. One could use higher memory scrypt parameters, and so the claim goes with memory bound functions that memory IO is less dissimilar between classes of machines than CPU speed (smartphone vs GPU). However you have to bear in mind also that scrypt actually has CPU memory tradeoffs, known about and acknowledged by its designer. I believe its realtively easy to construct a tweaked scrypt that doesnt have this problem. Also for the bitcoin/litecoin side of things I heard a rumor that there were people working on a litecoin ASIC. Bitcoin FTW in terms of proving the vulnerability of crypto password focussed KDFs to ASIC hardware. The scrypt time memory tradeoff issue maybe useful for efficient scrypt ASIC design. But there is a caveat which is the client/server imbalance is related to the difference in CPU power between mobile devices and server GPU or ASIC farms. While it is true that moore's law seems to have slowed down in terms of clock rates and serial performance the number of cores and memory architectures are still moving forward, and for ASICs density, clock rates and energy efficiency are increasing, and thats what counts for password cracking. But yes the longer term picture depends on the trend of the ratio between server GPU/ASIC performance vs mobile CPU. Another factor also is the mobiles are more elastic (variable clock, more cores) but to get full perf you end up with power drain and people dont thank you for draining their phone battery. It is possible for ARM eg to include an scrypt or a new ASIC unfriendly password KDF on the die perhaps if there was enough interest. The ready availability of cloud
Re: [cryptography] The Compromised Internet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/27/2013 09:35 AM, Eugen Leitl wrote: I don't see how a ham running a repeater backbone can prevent end to end encryption other than sniffing for traffic and actively disrupting it. I'm not sure tampering If enough hams (or one sufficiently angry lone ham operator) decide that this is a problem they'll organize a turkey hunt to triangulate the operator(s) and politely ask them to stop before the feds get called in. The thinking behind this seems to be that the amateur community has been graciously granted a small portion of the RF spectrum to experiment with. People (licensed hams or otherwise) who do specifically prohibited things within the amateur bands (like transmitting encrypted traffic or undocumented digital protocols (which may be indistinguishable from encrypted traffic)) can get some or all of the amateur band taken away. A lot of time and effort are spent every year by ham operators who don't want this, that, or the other sliver of the amateur band reassigned away from amateur use, and someone doing something dodgy within those spectra could have disasterous consequences. When Project Byzantium was adding amateur radio support for ISC milestone #3, these regulations were noted and discussed at length during initial reasearch. We also spoke with the ARRL during development, which expressed similar sentiments about crypto in the amateur bands (and passing traffic from unlicensed network users over the amateur band, incidentally). with transport is within ham ethics, though they definitely That would probably fall under jamming, which is definitely against ham ethics. don't understand the actual uses for encryption, at The hams I've spoken to seem to, but they also seem to fall into the camp of It's on the amateur bands, so if it's something I'd want to encrypt I'm not going to talk about it while chewing the rag anyway. least the old hands (are there even new hands?). Hello. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ Be the strange that you want to see in the world. --Gareth Branwyn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJJv54ACgkQO9j/K4B7F8GO0wCeMVOKo1YmC+/8VqUcm4+CGBek fk4AnjiH3UGQ/kqSzmSatwKFpSceISBq =n2mL -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PBKDF2 + current GPU or ASIC farms = game over for passwords (Re: TLS2)
On Mon, Sep 30, 2013 at 06:52:47PM +0100, Wasa wrote: Also the PBKDF2 / scrypt happens on the client side - how do you think your ARM powered smart phone will compare to a 9x 4096 core GPU monster. Not well :) How much would it help to delegate PBKDF2 / scrypt to smartphone GPU to break this asymmetry? It might help a little in the right direction, and so probably should be done; but I presume phone GPUs wont have that many cores nor high performance to compare to an AMD 7990 (4096x 1Ghz cores) even if it outperforms the phone CPU by a reasonable margin. since SRP and JPAKE use exponent_modulo sort of computation rather than a hash, any idea how this impacts attackers? how well can you paralellize a dictionary brute force for DL problem? I'm not expert so glad to hear about it. The A part of AKE password amplification, means that you cant break it via the DL stuff. The password only authenticates the diffie-hellman like key exchange, so it just is there to prevent MITM. You still have a full 2048 bit DL or 256-bit ECDL to attack and that is hopeless. The only attack is on the PBKDF2 stored on the server (or malware to grab the password on the client) Anyway and all that because we are seemingly alergic to using client side keys which kill the password problem dead. For people with smart phones to hand all the time eg something like oneid.com (*) can avoid passwords (split keys between smart phone and server, nothing on server to grind, even stolen smart phone cant have its encrypted key store offline ground to recover encrypted private keys (they are also split so you need to compromise the server and the client simultaneously). Also the user can lock the account at any time in event of theft or device loss. i like the idea. Any issue/complications with re-provisioning or multiple devices with same identity? If you lose one device you can replace the device enrole it authenticated by your other devices and securely restore access keys into it. It does support multiple devices, though each device also has a unique key as well as a common identity key so that individual devices can be revoked instantly if they are stolen. It uses some fun crypto like a blind MAC to do split key KDF and AKE type protocols. They have a recovery mechanism also I think if you simultaneously lose all our devices (laptop and smartphone) (user print out 128-bit key on registration). If the user doesnt do that they have to re-enrole as a new identity with oneid and the relying parties. I was thinking it could be a good tech for access to bitcoin online wallets and exchanges because also the transaction details are displayed for approval on the smart phone, so even if the laptop had bitcoin related password targetted malware on it, you could still securely transact if you read the transaction details on the smartphone before approving. Adam ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PBKDF2 + current GPU or ASIC farms = game over for passwords (Re: TLS2)
On 30/09/13 19:22, Adam Back wrote:
On Mon, Sep 30, 2013 at 06:52:47PM +0100, Wasa wrote:
Also the PBKDF2 / scrypt happens on the client side - how do you think
your ARM powered smart phone will compare to a 9x 4096 core GPU
monster. Not well :)
How much would it help to delegate PBKDF2 / scrypt to smartphone GPU to
break this asymmetry?
It might help a little in the right direction, and so probably should be
done; but I presume phone GPUs wont have that many cores nor high
performance to compare to an AMD 7990 (4096x 1Ghz cores) even if it
outperforms the phone CPU by a reasonable margin.
since SRP and JPAKE use exponent_modulo sort of computation rather
than a
hash, any idea how this impacts attackers? how well can you
paralellize a
dictionary brute force for DL problem? I'm not expert so glad to hear
about it.
The A part of AKE password amplification, means that you cant break it
via
the DL stuff. The password only authenticates the diffie-hellman like
key
exchange, so it just is there to prevent MITM. You still have a full
2048
bit DL or 256-bit ECDL to attack and that is hopeless.
The only attack is on the PBKDF2 stored on the server (or malware to grab
the password on the client)
right. I was think SRP/JPAKE where the server does not store
PBKDF2(salt,pwd) server-side, but rather it stores something like
g^{PBKDF2(pwd)}. If I break into server and get hold of all
g^{PBKDF2(pwd_i)}, can I parallelize the DL part?
Because I think one of the claims of SRP and JPAKE is not only to be
resistant to passive/active sniffing followed by offline brute-force,
but also to be more resistant against server compromise.
Idea?
If it turns out to be difficult to parallelize the brute-force, why not
move towards this? It would be an incremental improvement more likely to
be widely-accepted than brand-new schemes. JPAKE is a bit slow I presume
(given the number of required rounds), SRP is not and the patent expires
soon (if memory serves).
Anyway and all that because we are seemingly alergic to using client
side
keys which kill the password problem dead. For people with smart
phones
to hand all the time eg something like oneid.com (*) can avoid
passwords
(split keys between smart phone and server, nothing on server to grind,
even stolen smart phone cant have its encrypted key store offline
ground
to recover encrypted private keys (they are also split so you need to
compromise the server and the client simultaneously). Also the user
can
lock the account at any time in event of theft or device loss.
i like the idea. Any issue/complications with re-provisioning or
multiple devices with same identity?
If you lose one device you can replace the device enrole it
authenticated by
your other devices and securely restore access keys into it. It does
support multiple devices, though each device also has a unique key as
well
as a common identity key so that individual devices can be revoked
instantly
if they are stolen. It uses some fun crypto like a blind MAC to do split
key KDF and AKE type protocols.
They have a recovery mechanism also I think if you simultaneously lose
all
our devices (laptop and smartphone) (user print out 128-bit key on
registration). If the user doesnt do that they have to re-enrole as a
new
identity with oneid and the relying parties.
I was thinking it could be a good tech for access to bitcoin online
wallets
and exchanges because also the transaction details are displayed for
approval on the smart phone, so even if the laptop had bitcoin related
password targetted malware on it, you could still securely transact if
you
read the transaction details on the smartphone before approving.
so I wonder:
- with no server, what would be the user perception of security? and
would that prevents them from using such systems? Say, you log into your
online banking with no password; would user feel secure and use the service?
- would Facebook/twitter and co. like this sort of security where users
cannot log-in from anywhere from any device? Surely they prefer a bit
less security on client side + more ML detection server-side and more
users connected; right?
- I guess the sort of service you describe is great for large companies;
but the complexity might put off smaller ones. Thoughts?
- how different is the client cert approach compared to token used on
mobile devices (e.g. Google stores a unique token on smartphones to
access google services and hence requires no passwd)? Essentially it too
removes phishing problems, but seems more flexible. But it does not have
fancy crypto so maybe less exciting on an intellectual level :-)
Adam
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PBKDF2 + current GPU or ASIC farms = game over for passwords (Re: TLS2)
On 30/09/13 19:41, Wasa wrote: - with no server i meant with no password. Arguably we can have decoy password if users feel more secure with them :-) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PBKDF2 + current GPU or ASIC farms = game over for passwords (Re: TLS2)
On Mon, Sep 30, 2013 at 07:41:20PM +0100, Wasa wrote:
The only attack is on the PBKDF2 stored on the server (or malware to grab
the password on the client)
right. I was think SRP/JPAKE where the server does not store
PBKDF2(salt,pwd) server-side, but rather it stores something like
g^{PBKDF2(pwd)}. If I break into server and get hold of all
g^{PBKDF2(pwd_i)}, can I parallelize the DL part?
Well ok, this IRTF draft I was coincidentally just reading claims to be
marginally more efficient than SRP
https://datatracker.ietf.org/doc/draft-irtf-cfrg-augpake/?include_text=1
and has a verifier of that form.
You could parallelize it somewhat at a micro level but I dont think you need
to because you can just try lots of passwords in parallel against the same
verifier.
Because I think one of the claims of SRP and JPAKE is not only to be
resistant to passive/active sniffing followed by offline brute-force,
but also to be more resistant against server compromise.
No I do not think that is true. And I noticed the IRTF draft above's
security comments section confirms, it explicitly states that all it can
offer in the event of server compromise is that the attacker has to brute
force the PBKDF (aka function H in their terminology). (Actually that is
why I bothered to read the draft because of their title/abstract I wondered
if they had claimed to do better against server compromise and if so how as
that is beyond the state of the art AFAIK; turns out they are the same as
SRP etc).
Idea?
If it turns out to be difficult to parallelize the brute-force, why
not move towards this? It would be an incremental improvement more
likely to be widely-accepted than brand-new schemes. JPAKE is a bit
slow I presume (given the number of required rounds), SRP is not and
the patent expires soon (if memory serves).
I think SRP is not patented, and in fact is designed to be free from
reliance on any pre-existing patent details. There were some EKE patents
but coincidentally the AKE version just expired last month. Nice timing.
Adam
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] One Time Pad Cryptanalysis
* Lodewijk andré de la porte: [OTP assumptions] 1. Good source. P[i] must be independent to anything in P nor to the method to generate P. Random, you'd typically say. Fully unpredictable might be more clear (given people's unclarity about what's random). 2. No leak of P 3. Message integrity does not matter. 4. The security proof assumes there is only one message, ever. The proof is simply not correct for multiple messages, and OTP does not provide unconditional security for the multi-message case anyway. I'm really frustrated with people claiming OTP is insecure. I don't understand how it is and I cannot seem to construe any angles of attack. This attack would work against an OTP, too: Wright et al., Spot me if you can: Uncovering spoken phrases in encrypted VoIP conversations. http://cs.unc.edu/~fabian/papers/oakland08.pdf The basic issue has recently been rediscovered in the context of HTTP(S). ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Opinions on Internet Privacy
So then, the Sage in the comic is on the right path? http://tacobell.wikia.com/wiki/7-Layer_Burrito On Fri, Sep 27, 2013 at 3:02 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Paul Bakker p.j.bak...@offspark.com writes: So you agree we DO need an additional layer of symmetric and public key encryption, don't you? Six layers might not be enough!! Oh everyone knows that, if it doesn't have the full seven layers then you're not even trying. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PBKDF2 + current GPU or ASIC farms = game over for passwords (Re: TLS2)
On 2013-09-30, at 10:43 AM, Adam Back a...@cypherspace.org wrote: On Mon, Sep 30, 2013 at 02:34:27PM +0100, Wasa wrote: On 30/09/13 10:47, Adam Back wrote: PBKDF2 + current GPU or ASIC farms = game over for passwords. what about stronger pwd-based key exchange like SRP and JPAKE? Well SRP most certainly isn’t a solution to this problem. With SRP requires a shared secret key, so the attacker doesn’t even need to “crack a hash” after getting hold of a server’s password database. I don’t know enough about JPAKE to comment. Of course SRP can be used in a way to ensure that the shared secret is never reused among services, but I don’t actually know how SRP is used in practice. of even more concern an attacker who steals the whole database of user verifiers from the server can grind passwords against it. There is a new such server hashed password db attack disclosed or hushed up every few weeks. They are far more common than that. See http://blog.passwordresearch.com/2013/01/passwords-found-in-wild-for-december.html Undiscovered breaches are probably much more common than hushed up breaches, which in turn are more common that disclosed breaches. You know GPUs are pretty good at computing scrypt. I’ve been told by those who develop password cracking tools that (current) GPUs have a hard time with SHA512. So for the moment anyway, something like PBKDF2-HMAC-SHA512 should bring down the attacker-defender ratio. But this is hardly a long term solution and is focused on the specific architectures that exist today. However, it is what I am advocating as a temporary measure until we have something usable out of the Password Hashing Competition. The PHC is intended to find (spur the development of) a successor to PBKDF2 and scrypt. https://password-hashing.net But there is a caveat which is the client/server imbalance is related to the difference in CPU power between mobile devices and server GPU or ASIC farms. Yep. I work for a company that produces password manager that is used on mobile devices. The attacker will have much more to bring to the fight. All we can do is try to make the best use of the 500ms we think our users will put up with for key derivation. At the moment, that's PBKDF2-HMAC-SHA512 with the number of iterations initially calibrated to 500ms on the device where the data was created. But we are stuck with this asymmetry between attacker and defender, and have to design with it very much in mind. Anyway and all that because we are seemingly alergic to using client side keys which kill the password problem dead. I’m hardly allergic to that. Back in the 90s, I thought that this really would solve the password problem. I worked briefly on trying to initiate a project to develop a scheme where UK universities would sign client certs for members of the university. But, among other things, X.509 is a bitch. So I'm not so much allergic as pessimistic. For a long time I thought the password problem would be solved within the next few years. I’ve long seen client keys as the solution of the future. My fear is that it will remain the solution of the future. (Of course, given the business I’m in, my pessimism may be self-serving.) (Sure, a solution to the password problem would eliminate the need for the product that contributes to my livelihood, so maybe my pessimism is self-interested. But back when a chunk of my income was from fighting spam; I longed for the day I there would be no need for those services.) For people with smart phones to hand all the time eg something like oneid.com (*) ...(*) disclaimer I designed the crypto as a consultant to oneid. Cool. I will take a look. And even in my pessimism, I don’t see passwords (even with great password management tools) sticking around forever. It’s just that I’ve learned over time that, like unencrypted email, they have a disturbing staying power. Cheers, -j smime.p7s Description: S/MIME cryptographic signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
On Sun, Sep 29, 2013 at 8:57 AM, Michael Rogers mich...@briarproject.org wrote: We're also planning to support introductions through mutually trusted third parties. [...] Alice and Carol must trust Bob not to MITM the key exchange. It'd be nice if Alice and Carol could use some additional, out-of-band channel to authenticate the ephemeral DH exchange. Best I can think of are short auth strings (SAS), public-key fingerprints (if you added long-term identity keys), and PAKE. The tradeoffs are something like: * Key fingerprints and SAS are non-secret (unlike PAKE passwords) * SAS and PAKE can use short strings of several chars (unlike fingerprints) * Fingerprints can be exchanged before *or* after the ephemeral DH handshake (unlike PAKE passwords or SAS) * Fingerprints can be confirmed with 3rd parties or public records (unlike PAKE passwords or SAS) * Fingerprints and PAKE can be compatible with a single, unordered handshake exchange of ephemeral DH values, unlike SAS Trevor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PBKDF2 + current GPU or ASIC farms = game over for passwords (Re: TLS2)
Well clearly passwords are bad and near the end of their life-time with GPU advances, and even amplified password authenticated key exchanges like EKE have a (so far) unavoidable design requirement to have the server store something offline grindable, which could be key stretched, but thats it. PBKDF2 + current GPU or ASIC farms = game over for passwords. Before discarding passwords as yesterday's fish, glance at this: http://www.wired.com/opinion/2013/09/the-unexpected-result-of-fingerprint-authe ntication-that-you-cant-take-the-fifth --dan ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
