Re: [cryptography] PBKDF2 + current GPU or ASIC farms = game over for passwords (Re: TLS2)
On 1/10/13 05:00 AM, d...@geer.org 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. Before discarding passwords as yesterday's fish, glance at this: http://www.wired.com/opinion/2013/09/the-unexpected-result-of-fingerprint-authentication-that-you-cant-take-the-fifth I think the takeaway from this password debate (for me) is that any requirements listed for a TLS2 should be something like: Integrates well with current and future authentication methods. (and leave the contenders to duke it out...) iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] replacing passwords with keys is not so hard (Re: PBKDF2 + current GPU or ASIC farms = game over for passwords)
On Mon, Sep 30, 2013 at 10:00:12PM -0400, d...@geer.org wrote: Dr Adam Back wrote: 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 Well OK switching to physical fingerprints (fingerprint reader, iphone etc) is actually a step backwards, or only usable as a second factor. I imagine people have seen the gumi bear attacks, and someone already cracked the iphone fingerprint reader using a photograph of a print and some postprocessing, and fingerprints can be stolen. And Lucky has some gruesome alternatively low tech version also which doesnt bear thinking about. Fingerprints are a bad idea for those multiple reasons (stealable, non-secret (5th amendment argument in the article), have no secure challenge response possibility, left around via latent prints, lead to gruesome risks where you'd sooner give up the password if rubberhosed than have...) The point is rather to switch to keys. I was resisting referencing it (as its impolite to point at your own designs with commercial backing (*)) but I guess it needs spelling out that yes you can do this, and yes it can be easy to use and secure. Check out oneid.com. The federation server stores password verifiers - that are not grindable via theft, needing simultaneous compromise of the account holders smart phone/laptop (split keys). The smartphone/laptop has encrypted keys, with encryption that is also not offline grindable without simultaneously compromising the server verifier (more split-keys). Devices have unique keys and so can be offline revoked if stolen. Security is end to end between the client and the relying party (oneid or other party runnng the federation server cant even tell which relying parties users are enrolled with nor logging into). Stolen/broken devices can be replaced via secure pairing with remaining devices. Simutlaneous theft of all devices is coped with via a recovery code, or re-enrollment with a new identity (and new relying party account re-association via the respective relying party enrollment process) if the user ignores the recovery code setup. There is still login transaction security in the system if the pc has malware, the attacker has root on the federation server, the attacker has all of your pins and passwords (that protect device private keys), and the attacker has remote compromise but not code modification ability on the relying party, just so long as you have your smartphone without targetted malware, in your control. That could and should be extended with a key contribution from the smartphone SIM or TPM trusted-agent once hardware catches up. Its easy to use, just read the transaction confirmation on your smart phone and click a button, thats the user experience. Even if the laptop is compromised by malware targetting your transaction (eg say online bitcoin wallet auth) the worst it can do is block your transaction - presuming you actually carefully read the transaction before approving on your smartphone screen. Adam (*) historically I designed their crypto protocols as a consultant but I have no financial stake. oneid are khosla ventures funded the CEO is Steve Kirsch a serial entrepreneur with $1b of previous company exits to his name. ___ 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 1/10/13 11:56 AM, ianG wrote: On 1/10/13 05:00 AM, d...@geer.org 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. Before discarding passwords as yesterday's fish, glance at this: http://www.wired.com/opinion/2013/09/the-unexpected-result-of-fingerprint-authentication-that-you-cant-take-the-fifth I think the takeaway from this password debate (for me) is that any requirements listed for a TLS2 should be something like: Integrates well with current and future authentication methods. (and leave the contenders to duke it out...) Which leaves open the question (in my mind) as to whether to require this: Both end points must authenticate each other. iang ___ 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)
Which leaves open the question (in my mind) as to whether to require this: Both end points must authenticate each other. Keep in mind that the client side was deliberately crippled in browsers for privacy reasons. Support used to be much better—you could transparently created a client certificate which would automatically be used for future TLS handshakes. ___ 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 1/10/13 12:22 PM, Florian Weimer wrote: Which leaves open the question (in my mind) as to whether to require this: Both end points must authenticate each other. Keep in mind that the client side was deliberately crippled in browsers for privacy reasons. Support used to be much better—you could transparently created a client certificate which would automatically be used for future TLS handshakes. Right, another requirement: Minimise the leakage of identifying information to eavesdroppers. These two requirements then might appear opposed. Or might not, there are many ways to skin the connection cat. iang ___ 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 22:11, Jeffrey Goldberg wrote: 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 think that's true. https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol The host pwd is of the form g^x where x=H(p,s) same goes for JPAKE. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] three crypto lists - why and which
On 09/30/2013 06:27 AM, Adam Back wrote: 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 It's probably not worth mentioning the sci.crypt newsgroup, is it? There is *occasionally* some intelligent discussion there. -- 2C+CMQjIjaCehU0V2o3RDf0rk+jaijnRuQ3QhUj/vRtGGYTwncLy7AQU3Dap Hg10jLJ+tw8QBkqk1wfpeg/Z1eiT4Lbo13RB1kCKBI6AtBN1DJTDtENTeaAz XE9gTWVfi/Zpa4RPynL4zXTTDrRo4OWU5pUTOhqKU+GcHj85/SsjG4iV2AY5 AhuYwP42EuJ1aPq4JPVSJ6j/UX+jNM0wyUPbBx0Z0T8Jk3BuJ/xoHjwGdVxR FlKlcwtE3P5ocGXk90Pl25sZDqTqT08vXpOvSw1rMULG3xSkznJTM5KmQmSY /Pyr9uKqhryeJ2b+oX1iis7KcVwY5Q7RGJuR9p8uUg== ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Unbreakable Cipher
On 09/25/2013 03:51 PM, Jonathan Katz wrote: On Wed, Sep 25, 2013 at 1:30 PM, Greg Rose g...@seer-grog.net mailto:g...@seer-grog.net wrote: On Sep 25, 2013, at 9:40 , Jonathan Katz jk...@cs.umd.edu mailto:jk...@cs.umd.edu wrote: Every cipher is breakable, given enough traffic: in principle, yes, as long as the traffic (formally, the entropy of the traffic) is larger than the key length. You misstated this. It's breakable if the *redundancy* of the traffic is larger than the key length. Not so; this is most easily seen by taking the uniform distribution over n-bit messages, in which case the entropy is n and the redundancy is 0. regards, Greg. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography If the message is chosen from a uniform distribution over n bits (and assuming that the message is not used for something else after it is deciphered), the adversary will not be able to distinguish a correctly deciphered message from an incorrectly deciphered message, no matter how short the key is in comparison to the data. Now, you could easily argue that there is absolutely no reason to send a message with those properties, but that isn't really the point. -- KmNJcjeUDRXMu6riH0KAK9Og8WAaAT8oXcbnFIij5djCP4v+6GTFxnHoHzvW NTL+4ZPiGUqerypkfsDfEOcO+i6ZlY59G79tEMwR0fsKO9w9MLbv6Odz5RxY JZgUsZJ8lZWx/zBsL4oqU60k+EFbV14fSUVoaRpazy1ozgQFdi2SdfHTB41y 7SsMX/JlevnnBj/GhUyFlXPr2kwechOSy5W74iVbUaOpeYMqNIx3jCmZfjez Gi+sS8ghQB8y5b9NgYTlR7HBh+leObqQX/R5bAkyPyh2oDOlFbD2HQiCsiB9 Uj/qLtG3CaZQVtkCSC1s3NschLBgWHfQ9xkb3Peqzg== ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Why is emailing me my password?
The several crypto lists run by mailman email passwords monthly. Open crypto lists are not meant to be more trustworthy than open crypto. At 10:28 AM 10/1/2013, you wrote: This falls somewhere in the land of beyond-the-absurd. Just got this message from your robot: On Oct 1, 2013, at 5:00 AM, mailman-ow...@metzdowd.com wrote: If you have questions, problems, comments, etc, send them to mailman-ow...@metzdowd.com. Thanks! Passwords for g...@kinostudios.com: List Password // URL cryptogra...@metzdowd.comiPoopInYourHat http://www.metzdowd.com/mailman/options/cryptography/greg%40kinostudios.com So, my password, iPoopInYourHat, is being sent to me in the clear by your servers. Of all the places on the internet, this would be on the last places I would expect this to happen. - Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. ___ The cryptography mailing list cryptogra...@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)
On Tue, Oct 1, 2013 at 3:08 AM, Adam Back a...@cypherspace.org wrote: But I do think it is a very interesting and pressing research question as to whether there are ways to plausibly deniably symmetrically weaken or even trapdoor weaken DL curve parameters, when the seeds are allowed to look random as the DSA FIPS 186-3 ones do. See slide #28 in this djb deck: http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4x3.pdf Specifically: http://i.imgur.com/C7mg3T4.png If e.g. the NSA knew of an entire class of weak curves, they could perform a brute force search with random looking seeds, continuing until the curve parameters, after the seed is run through SHA1, fall into the class that's known to be weak to them. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)
On Tue, Oct 01, 2013 at 08:47:49AM -0700, Tony Arcieri wrote: On Tue, Oct 1, 2013 at 3:08 AM, Adam Back [1]a...@cypherspace.org wrote: But I do think it is a very interesting and pressing research question as to whether there are ways to plausibly deniably symmetrically weaken or even trapdoor weaken DL curve parameters, when the seeds are allowed to look random as the DSA FIPS 186-3 ones do. See slide #28 in this djb deck: If e.g. the NSA knew of an entire class of weak curves, they could perform a brute force search with random looking seeds, continuing until the curve parameters, after the seed is run through SHA1, fall into the class that's known to be weak to them. Right but weak parameter arguments are very dangerous - the US national infrastructure they're supposed to be protecting could be weakened when someone else finds the weakness. Algorithmic weaknesses cant be hidden with confidence, how do they know the other countries defense research agencies arent also sitting on the same weakness even before they found it. Thats a strong disincentive. Though if its a well defined partial weakening they might go with it - eg historically they explicitly had a go at in public requiring use of eg differential cryptography where some of the key bits of lotus notes were encrypted to the NSA public key (which I have as a reverse-engineering trophy here[1]). Like for examle they dont really want foreign infrastructure to have more than 80 bits or something close to the edge of strength and they're willing to tolerate that on US infratructure also. Somewhat plausible. But the more interesting question I was referring to is a trapdoor weakness with a weak proof of fairness (ie a fairness that looks like the one in FIPS 186-3/ECDSA where we dont know how much grinding if any went into the magic seed values). For illustration though not applicable to ECDSA and probably outright defective eg can they start with some large number of candidate G values where G=xH (ie knowing the EC discrete log of some value H they pass off as a random fairly chosen point) and then do a birthday collision between the selection of G values and diffrent seed values to a PRNG to find a G value that they have both a discrete log of wrt H and a PRNG seed. Bearing in mind they may be willing to throw custom ASIC or FPGA supercomputer hardware and $1bil budgt at the problem as a one off cost. Adam [1] http://www.cypherspace.org/adam/hacks/lotus-nsa-key.html ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] replacing passwords with keys is not so hard (Re: PBKDF2 + current GPU or ASIC farms = game over for passwords)
On Tue, Oct 1, 2013 at 2:12 AM, Adam Back a...@cypherspace.org wrote: ... And Lucky has some gruesome alternatively low tech version also which doesnt bear thinking about. i'm curious about defeating the liveness detection of fingerprint readers using a severed digit. or is non-trivial liveness detection only a feature in the most expensive readers? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)
On Tue, Oct 1, 2013 at 9:51 AM, Adam Back a...@cypherspace.org wrote: Right but weak parameter arguments are very dangerous - the US national infrastructure they're supposed to be protecting could be weakened when someone else finds the weakness. As the fallout from the Snowden debacle has shown (with estimates of the damage to US businesses in the tens of billions) the NSA seems to be unconcerned with the blowback potential of doing things that are potentially damaging when discovered. I wouldn't put it past them to intentionally weaken the NIST curves. That said, my gut feeling is they probably didn't. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)
On 2013-10-01, at 12:54 PM, Tony Arcieri basc...@gmail.com wrote: I wouldn't put it past them to intentionally weaken the NIST curves. This is what has changed. Previously, I believed that they *wouldn’t* try to do something like that. Now we need to review things in terms of capability. That said, my gut feeling is they probably didn’t. My exceedingly untrained intuition conforms to yours. But we do need to evaluate whether there are non-implausible mathematical and procedural mechanisms by which they could have. So the question for me is how implausible is it for there to be whole families of weak curves known to the NSA. I simply don’t understand the math well enough to even begin to approach that question, but … If the NSA had the capability to pick weak curves while covering their tracks in such a way, why wouldn’t they have pulled the same trick with Dual_EC_DRBG? If they could have made the selection of P and Q appear random, it seems that they would have. I know that this isn’t the identical situation, but again my (untrained) intuition suggests that there are meaningful similarities in ways they could (or couldn’t) cover their tracks. Cheers, -- Jeffrey Goldberg smime.p7s Description: S/MIME cryptographic signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] replacing passwords with keys is not so hard (Re: PBKDF2 + current GPU or ASIC farms = game over for passwords)
On Tue, Oct 01, 2013 at 10:25:10AM -0700, coderman wrote: On Tue, Oct 1, 2013 at 2:12 AM, Adam Back a...@cypherspace.org wrote: ... And Lucky has some gruesome alternatively low tech version also which doesnt bear thinking about. i'm curious about defeating the liveness detection of fingerprint readers using a severed digit. or is non-trivial liveness detection only a feature in the most expensive readers? Hey that was the unmentionable part! But surely that must be true because if moistened gumi-bear can do the trick surely a finger without blood flow can. (Eww thanks for that). Most of these biometrics seem pretty stupid. There was one where they printed out a colour photo of the person and waved it in front of the camera to give an impression of motion for facial recognition. Its probably a basic factor of the noise rate in the data, the limits of recognition, and the tolerable false negative rate = biometrics are either insecure or unreliable at least for the mid term. But also you mention expensive biometric readers - some of the rubber facemasks are damn convincing to the human eye (eg if you watched Bryan Cranston breaking bad thing on Jimmy Fallon skip to 5:25 http://www.youtube.com/watch?v=XEQk1_F7sL0) - surely that can fool better facial readers than waving an inkjet printed photo. Probably similar for fingers - ie readers can up, but your adversary can also make better than prank gummy bear fake fingers to if thats your threat model. Biometrics - stupid idea IMO. Adam ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)
On Tue, Oct 1, 2013 at 9:00 PM, Jeffrey Goldberg jeff...@goldmark.orgwrote: On 2013-10-01, at 12:54 PM, Tony Arcieri basc...@gmail.com wrote: I wouldn't put it past them to intentionally weaken the NIST curves. This is what has changed. Previously, I believed that they *wouldn’t* try to do something like that. Now we need to review things in terms of capability. That said, my gut feeling is they probably didn’t. My exceedingly untrained intuition conforms to yours. But we do need to evaluate whether there are non-implausible mathematical and procedural mechanisms by which they could have. So the question for me is how implausible is it for there to be whole families of weak curves known to the NSA. I simply don’t understand the math well enough to even begin to approach that question, but … If the NSA had the capability to pick weak curves while covering their tracks in such a way, why wouldn’t they have pulled the same trick with Dual_EC_DRBG? If they could have made the selection of P and Q appear random, it seems that they would have. I know that this isn’t the identical situation, but again my (untrained) intuition suggests that there are meaningful similarities in ways they could (or couldn’t) cover their tracks. Yes. Apparently. Purely for the entertainment value to the audience here, I offer that it occurred to me that the suspect P-Q could have been a test case provided by the NSA, along the lines of Given how the algorithm is supposed to work, if we corrupt the P-Q pair by making them non-random using a specific mathematical relationship between them, then the algorithm should be provably not secure. Demonstrating this should increase the confidence that the correctly implemented algorithm is secure. Then what happened is some arrogant scientist at NIST (full disclosure--I was formerly a NIST employee, and the terms of my departure still burn as a fire in the pit of my stomach) conveniently forgot to put the correct ones in the standard, or did it on purpose since Anyone of modest skill in cryptography will detect the problem and come up with their own P-Q pair correctly. Anyone who doesn't deserves what they get. There are, in my estimation, people that arrogant employed by NIST. Look here http://blog.cryptographyengineering.com/2013/09/the-many-flaws-of-dualecdrbg.html#! Cheers, -- Jeffrey Goldberg ___ 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] [Cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)
On Tue, Oct 1, 2013 at 12:00 PM, Jeffrey Goldberg jeff...@goldmark.orgwrote: If the NSA had the capability to pick weak curves while covering their tracks in such a way, why wouldn’t they have pulled the same trick with Dual_EC_DRBG? tinfoilhatThey wanted us to think they were incompetent, so we would expect that Dual_EC_DRBG was their failed attempt to tamper with a cryptographic standard, and so we would overlook the more sinister and subtle attempts to tamper with the NIST curves/tinfoilhat -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] oneid single-sign on stuff (Re: PBKDF2 + current GPU or ASIC farms = game over for passwords (Re: TLS2)
I didnt see your comment lower down before (quoting got too long). On Mon, Sep 30, 2013 at 07:41:20PM +0100, Wasa wrote: [oneid] 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. so I wonder: - with no server[correction password], what would be the user perception of security? Say, you log into your online banking with no password; would user feel secure and use the service? There would be still a password or a pin typically so that perception is still there somewhat. But the password is used locally only (together with a server input to prevent offline grinding to decrypt the private key in event of stolen device). The key derived from the password/pin and server input is used to decrypt the device private key. The device private key makes a signature as part of an end2end secure challenge response with the relying site. and would that prevents them from using such systems? There is a bootstrap problem - oneid has to gather some relying parties and persuade them to integrate the system. They have integrated with some commerce and banking platforms and some partners. You could imagine it being like other 3rd party integration where a bank might use also their own info on top (account number etc) though that can be handled by oneid (it supports encrypted relying party specific account info and form filling). - 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? In principle as I understand it user account theft, locking themselves out by forgetting passwords and resets cost big players like facebook/twitter/paypal etc big bucks like millions annually. Security cleanup after the inevitable server compromise and hashed password db theft cant be a lot of fun either plus the negative PR if it comes out publicly. Real disservice to the users too who often use same or similar passwordws on multiple sites. So you would think there is a business case to improve things. Similar password management is a pain and people leave new sites by clicking back when faced with yet another please signup. You see it now in some sites starting to let you login with unrelated twitter or facebook just to save their users the pain of managing yet another password from even an unwanted relationship. (All you want to do is read the new article or report!) So then there should be an interest for the company to allow users to authenticate. The uptake of twitter/facebook in that role bears that out. But it also not very privte - I dont know what facebook are doing but they're probably prone to blog about your login or enrollment on your facebook wall, if you're not careful. They certainly know where you logged in and where you enrolled. (Which oneid takes pains to prevent itself from learning as all relying party traffic is direct from user to relying party). - I guess the sort of service you describe is great for large companies; but the complexity might put off smaller ones. Thoughts? Well from a user point of view its very simple. The site integration is supposedly rather easy also, though I know less about that. https://developer.oneid.com/ there are SDKs and APIs. - 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. Google device auth is on the better end of things, but oneid its a generalization of that concept - because its federated in a way where you dont have to trust the federation server operator, and yet can use the same device to login to multiple mutually distrusting services operated by different relying parties. Also oneid has server split key so you can not access the device key without pin/password, and 3 wrong guesses locks your device as enforced by the server. The server also cant access your device private key, you would need the device and the server db (eg a stolen copy or subpoena of the server factor for a given user) plus then to grind the actual password. I'm not sure if google would track the login if used by a third party - I guess they would want to because they like to track and record everything for posterity in case they can squeeze some latent ad revenue out of it. (No evil and all but thats a big database for
Re: [cryptography] replacing passwords with keys is not so hard (Re: PBKDF2 + current GPU or ASIC farms = game over for passwords)
On Tue, 1 Oct 2013, Adam Back wrote: The point is rather to switch to keys. I was resisting referencing it (as its impolite to point at your own designs with commercial backing (*)) but I guess it needs spelling out that yes you can do this, and yes it can be easy to use and secure. Check out oneid.com. [[...]] Its easy to use, just read the transaction confirmation on your smart phone and click a button, thats the user experience. [[...]] How do I use this if I'm somewhere with no cellphone reception? How do I use this if my cellphone just broke down? How do I use this I've I've just landed in (say) Ireland and discovered that my I-thought-it-was-unlocked cellphone is in fact locked to a Canadian carrier and will only make emergency calls. (This happened to me a few months ago. Even a locally-bought-in-Ireland simcard didn't work in that phone.) ciao, -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy IUCSS, Indiana University, Bloomington, Indiana, USA There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time. -- George Orwell, 1984 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] more oneid stuff 2-factor when smartphone offline scenarios (Re: replacing passwords with keys is not so hard (Re: PBKDF2 + current GPU or ASIC farms = game over for passwords))
On Tue, Oct 01, 2013 at 04:28:01PM -0400, Jonathan Thornburg wrote: On Tue, 1 Oct 2013, Adam Back wrote: The point is rather to switch to keys. Check out oneid.com. [[...]] Its easy to use, just read the transaction confirmation on your smart phone and click a button, thats the user experience. [[...]] How do I use this if I'm somewhere with no cellphone reception? If you're offline it wont work because you wont be able to obtain the server contribution to go with the password you know for the KDF to unlock your smartphone private key. (Technically the key could be cached, but you probably dont want to make that too lax or your device could be stolen in unlocked state). But the use case is to single signon to an online service so thats probably not a (new) problem. Not online = no access services you need web single sign on for? If you're online on your laptop via wifi you can probably (but not 100%) get online with your smartphone. (The gap being the very odd wretched hotel that tries to charge for wifi by number of devices). No particular support from oneid but in principle you could reverse tether your smartphone to your laptop but the setup for that is not convenient for novice users, and many wifi chipsets cant be a hotspot and client simultaneously. I guess there's stll bluetooth reverse tether, but again not easy to setup for novice users and probably the reverse direction to what handset and computer OS aim to support. How do I use this if my cellphone just broke down? You get a replacement cellphone and pair it to your account. It is possible to chose to login to sites with a lower security margin, by flagging them to be allowed to login with laptop only (making the smartphone unnecessary). However that is vulnerable to malware, and in oneid the relying party can insist on having the smartphone level of security (and they can tell if their policy was applied as there are 2 signatures in the challenge response rather than 3). You can also pair multiple smartphones/tablets to your account, eg use your tablet or partner's smartphone if travelling together. I guess most people dont carry two smartphones, but smartphone + tablet + laptop is maybe not that rare. But otherwie I think for high security its the price you pay. You dont want targetted malware on your laptop to empty your bitcoin web wallet so you have to tolerate the 2nd factor. Its more useful than a OTP keyfob (secureid and clones) because you can see the transaction details you are authorizing. OTP keyfobs can be repurposed by laptop malware to authorize something different from what you think you are entering it for. Try locking yourself out of your online banking while travelling by forgetting a password. An international cell call to their online support etc is not much fun either. The alternative has its failure modes as well as being significantly insecure. You'd wonder if oneid would be amenable to trying to be extremely open and making reference implementation and open standard like openid if people thought the idea is a net improvement. That could be one way to overcome selfish identity ownership thinking amongst relying parties. And also it is a fair concern from individual web developers of what happens to their login mechanism if oneid went out of business. The model actually open, that anyone can run a federation server, analogous in that sense to openid. Adam ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)
On 2013-10-02 06:10, Tony Arcieri wrote: tinfoilhatThey wanted us to think they were incompetent, so we would expect that Dual_EC_DRBG was their failed attempt to tamper with a cryptographic standard, and so we would overlook the more sinister and subtle attempts to tamper with the NIST curves/tinfoilhat� The NSA is conspiratorial. The NSA, in choosing the NIST curves, chose them in one way and said it was choosing them in another way. One lie, all lies. If a liar, looking for consistency is pointless. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)
On 2013-10-01, at 3:10 PM, Tony Arcieri basc...@gmail.com wrote: On Tue, Oct 1, 2013 at 12:00 PM, Jeffrey Goldberg jeff...@goldmark.org wrote: If the NSA had the capability to pick weak curves while covering their tracks in such a way, why wouldn’t they have pulled the same trick with Dual_EC_DRBG? tinfoilhatThey wanted us to think they were incompetent, so we would expect that Dual_EC_DRBG was their failed attempt to tamper with a cryptographic standard, and so we would overlook the more sinister and subtle attempts to tamper with the NIST curves/tinfoilhat Well of course I’d thought of that. (I think the difference between the tinfoil hat crowd and the rest of us is not in what we can imagine. If we can’t imagine things like that, then we aren’t doing our jobs. I think the difference is which of our imaginings we consider to be meaningfully plausible.) Anyway, my “answer” to that is that it would be far far better for them to conceal that they were sabotaging standards at all. After all, they’d earned a great deal of trust and respect for helping to make standards better. So unless they anticipated something like the Snowden leaks and were playing a very long (and risky game),… it just doesn’t pan out. Either way -- and to reiterate what we’ve all learned -- they are willing to sabotage at least some standards. We can’t ignore that fact when looking at standards and the standards process. Cheers, -j -- Jeffrey Goldberg ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] replacing passwords with keys is not so hard (Re: PBKDF2 + current GPU or ASIC farms = game over for passwords)
On 10/01/2013 10:12 AM, Adam Back wrote: its impolite to point at your own designs Heh, I guess its ok to pile on so:-) HOBA [1,2] is our similar idea. More focused on lower assurance settings for now at least, on the basis that those passwords are arguably more likely to leak and on being a straight drop-in replacement a site can do all by themselves. But the goal of getting rid of crappy passwords is the same and is laudable mostly regardless of the scheme specifics. S. [1] https://tools.ietf.org/html/draft-ietf-httpauth-hoba [2] https://hoaba.ie/ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] One Time Pad Cryptanalysis
2013/9/30 Florian Weimer f...@deneb.enyo.de 3. Message integrity does not matter. 4. The security proof assumes there is only one message, ever. 3 and your paper about VOIP regard traffic analysis. I'm not sure what else 3 refers to. Certainly a known plaintext attack would negate that part of the message, but then it wasn't very encrypted in the first place, was it? Then you can of course replace part of the message, and if you have a partial plaintext you might even make it not-garbled, but then still I think you should apply mixing/scrambling before OTP'ing your plaintext. There's quite a selection of ways to do that. I agree this is relevant in some applications. In others it can be fixed. For example by mixing by doing AES (or something better) with the first x bits of the OTP. Just to mix, not to encrypt. But then a (mayor) flaw in AES could provide the opponent with a partial plaintext attack against AES an attack on whatever touched that data in the OTP'ed output. Hmm. Even a simple mixer exclusively using the beginning of the pad for secret information must be able to simply mix the input. AES should be able to do that much, I doubt it would so broken it wouldn't do that. And of course I don't think we can consider traffic analysis a breach of encryption. Not that I think it's not breach. But it's not related to OTP. You could apply traffic analysis even on plaintext. Point is that it's a breach of security from another piece of the system (the whole) than the one we are discussing. 4 regards the notion that a One-Time-Pad is only used One-Time. I agree, but reuse of any form will either make P leak or it will not be a problem. There's no real reason to use P multiple times and it is very hard to be sure you are not leaking information about P when you reuse. I judge this 4th requirement to be redundant to requirement 2. Although it is still correct, of course. I might've misunderstood the meaning of these points. I'd like to have misunderstood, then there is something to learn. P.S.: Why is that paper 15 pages long? I mean, really. It's just correlating input letter (in voice), where possible, with the output bandwidth and it's changes. Of course there's hundreds of little annoying things from several disciplines. I guess they did it thoroughly, then the paper should be thorough. Fine. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] more oneid stuff 2-factor when smartphone offline scenarios (Re: replacing passwords with keys is not so hard (Re: PBKDF2 + current GPU or ASIC farms = game over for passwords))
On Tue, 1 Oct 2013, Adam Back wrote: The point is rather to switch to keys. Check out oneid.com. [[...]] Its easy to use, just read the transaction confirmation on your smart phone and click a button, thats the user experience. [[...]] How do I use this if I'm somewhere with no cellphone reception? The use case I was raising is where I have internet access (whether wired or wifi is immaterial) but no cellphone reception. This occurs in some rural areas, and in hilly areas in some cities. It would be interesting to know how common this situation is. I.e. what percent of the valid logins to online service occur at a place and time where the user doesn't have cellphone reception? Have there been any (well-done) surveys to estimate this? ciao, -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy IUCSS, Indiana University, Bloomington, Indiana, USA There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time. -- George Orwell, 1984 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
