[cryptography] Reflection Attacks in Challenge/Response Protocols
Hi All, When a symmetric key based challenge response is used, an attacker can perform a reflection attack by starting a second instance of a protocol and having the server answer its own questions. To guard against the attack, is it sufficient to ensure all challenges sent from server to client are equal to 1 mod 2; and all client to server challenges are equal to 0 mod 2? Is it enough to break the symmetry? Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Reflection Attacks in Challenge/Response Protocols
The client and the server shouldn't both generate responses exactly the same way with the same key, no. If you use HMAC, I think including a simple identifier would be good enough. Something like this: HMAC(key, device ID + counter + timestamp), where the server and client has different IDs. Den 24 aug 2013 09:32 skrev Jeffrey Walton noloa...@gmail.com: Hi All, When a symmetric key based challenge response is used, an attacker can perform a reflection attack by starting a second instance of a protocol and having the server answer its own questions. To guard against the attack, is it sufficient to ensure all challenges sent from server to client are equal to 1 mod 2; and all client to server challenges are equal to 0 mod 2? Is it enough to break the symmetry? Jeff ___ 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
[cryptography] no-keyring public
hi list, i had an epiphany today, and i wonder if such a thing already exists or not. so the usual thing is to create a key pair, store the private key encripted with a password. we automatically get a two factor authentication, we have a know and a have. okay, but what if we don't want this, and we want our old password only, no keyring approach? we can do that. how about this? stretch the password with some KDF, derive a seed to a PRNG, and use the PRNG to create the the key pair. if the algorithm is fixed, it will end up with the same keypair every time. voila, no-keyring password-only public key cryptography. do you see any downsides to that, besides the obvious ones that follow from the no-keyring requirement? (slow, weak password.) has anybody done something like that already? does it have a name? regs, Krisztián ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] no-keyring public
On Aug 24, 2013, at 11:30 AM, Krisztián Pintér pinte...@gmail.com wrote: we can do that. how about this? stretch the password with some KDF, derive a seed to a PRNG, and use the PRNG to create the the key pair. if the algorithm is fixed, it will end up with the same keypair every time. voila, no-keyring password-only public key cryptography. do you see any downsides to that, besides the obvious ones that follow from the no-keyring requirement? (slow, weak password.) You mean like a Bitcoin brain wallet? And yes, the downside is that they're very susceptible to brute force attacks. I suppose this is more the case with Bitcoin wallets than with other signature schemes. Will signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] no-keyring public
Szervusz Kristián. On August 24, 2013 at 11:29:57 AM, Krisztián Pintér (pinte...@gmail.com) wrote: so the usual thing is to create a key pair, store the private key encripted with a password. we automatically get a two factor authentication, we have a know and a have. Yep. We need both the private key file and the password to decrypt it. I’ve called this “one and a half factor” at times. how about this? stretch the password with some KDF, derive a seed to a PRNG, and use the PRNG to create the the key pair. if the algorithm is fixed, it will end up with the same keypair every time. voila, no-keyring password-only public key cryptography. I’m not sure why this would be preferable to simply storing the password protected private key in a public place. It has the identical benefits in that the user doesn’t need to maintain and copy their private key from place to place, and it shares the same basic problem (you need a very good KDF and password), but it introduces other problems: 1. In your system the KDF for creating the seed to PRNG can’t be salted. And so two people with the same password will end up with the same key pair. (You could store the salt in some public place, but if you are doing to do that, you might as well store the encrypted private key.) 2. You can’t change your password without changing your key pair. (Though password changes don’t do a lot of good with the current system either.) 3. Key generation is slow and complex, presenting a greater opportunity for side channel attacks. 4. This means that we can never improve key generation. The particular heuristics that are used know with the identical parameters are things things that we will be stuck with. 5. Key generation is slow (as you mentioned) If your goal is to not have to have people keep track of their private key files, I’m not sure that this is a good way to do that. (Though I recently encountered this problem. I didn’t have my private keys on my “travel” laptop. I thought I’d saved them in my password manager, but it turns out I’d only saved the public keys.) Szia, Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] no-keyring public
adjisten :) 1. In your system the KDF for creating the seed to PRNG can’t be salted. nope, it can't be. And so two people with the same password will end up with the same key pair. for this reason, and others, a really strong key phrase is needed for that reason. this is definitely a problem, but it is a problem that i believe follows from the no-keyring requirement. i see no way around it. 3. Key generation is slow and complex, presenting a greater opportunity for side channel attacks. that is also a problem, since the algo probably needs to be implemented and executeed in a lot of places. otherwise, why no keyring? it is less of a problem if we have widely used high quality software libraries. 4. This means that we can never improve key generation. we can. we can incorporate any easy to remember information in the key generation process. like version number, purpose, etc. it is technically part of the password, except does not have to be hard to guess. quite the opposite, it has to be straightforward to remember. kinda like i choose SSH1, SSH2 RSA, SSH2 DSA in puttygen. as a weird approach, the program can even try to guess these. it can try to generate keypairs with different settings, and see which results in the proper public key. If your goal is to not have to have people keep track of their private key files, I’m not sure that this is a good way to do that. do you see any weaknesses in this proposal that does not apply to all keyring-less, single-factor, pure-pwd approaches? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Reply to Zooko (in Markdown)
Hey Z, On 23/08/13 18:21 PM, Zooko Wilcox-OHearn wrote: Dear Jon: Thank you for your kind words and your detailed response. I am going to focus only on the issue that I think is most relevant and urgent for your customers and mine. That urgent issue is: what's the difference between the now-canceled Silent Mail product and the products that you are still offering, such as Silent Text? I think this issue is important, and it is good to get all the opinions out in the air. And I especially like that we can debate the merits of an engineering decision with a venture like Secret Circle, and for once not have to deal with the normal corporate mouthpieces out of which stream very fine and pretty streams of bubbles. That said... ... This changes the equation, because it means not only can the U.S. federal espionage authorities say Backdoor all of your customers or close your business., they can also say Backdoor all of your customers or go to jail.. As the owner and CEO of a privacy-protecting service (https://LeastAuthority.com) and a U.S. citizen, and as the father of three precious boys who do not want to be separated from me for any length of time, this concerns me greatly. I'm not convinced that the US feds can at this stage order the backdooring of software, carte blanche. Is there any evidence of that? (I suspect that all their powers in this area are from pressure and horse trading. E.g., the export of cryptomunitions needs a licence...) ... Why do you think that this scenario is plausible? I don't think it is plausible. Instead, I think the conversation would go like this: Silent Circle: … and then wait for all of our customers to automatically upgrade to the new version! Attacker: Okay. Do that. So at this stage, SC can ask for the order from the court that particularises that request. The point being here that the court can easily order the handover of documents that are kept. It cannot however easily order the business to go and get the documents it doesn't have. The court does not typically interfere in the business of business; rather this is all about an intermediate step of facilitating the 'discovery' of evidence that might be available, for some investigation. Ordering the discovery of evidence that didn't hitherto exist, for a crime that isn't as yet to be discovered raises ... difficulties. ... The stated reason was that the US federal government could compel Silent Circle to backdoor the Silent Mail service. That same reason applies today to the Silent Text service and the other services that Silent Circle is still operating. I would be surprised if there was a single stated reason. It makes no sense for any provider of any business to suddenly roll over and say eek when the feds turn up and go boo. Perhaps this is in part because, as far as I can see, the decision makes perfect sense. The decision is really about the engineering differences between email and chat. I would do the same. In short, email is practically rather difficult to secure. Because, with a nod to the other thread, amongst many reasons: it is a standards-based monster, it has no limits to who and where, lots and lots of metadata is spilt out, and finally we need *all* the clients to be fixed to win so network economics are against us. Whereas chat is securable. Chat typically is a closed system, one client, or at least one protocol provider, and the metadata can be limited. The difference is significant. You can see this in the large with something like OTR which is trying to secure all other chat systems. As we get broader and more inclusive, the security provided starts to look more limited in its utility. I am assuming that Silent Circle are doing a private chat system. That's easy to secure (I mean, easy in the hand-waving sense in a crypto group). But email ain't that closed system, and any promise that SC makes looks increasingly as tho it isn't worth making, and I commend them for trying, and then realising they are not going to be able to keep it in any meaningful way. Currently, the US federal espionage agencies can compel Silent Circle to secretly provide access to all of Silent Circle's customers' private communications. I do not believe that to be the case. As yet. I think they can compel the communications that SC might have, but not their customers' private comms. That's too bad. But it is fixable! But to fix it starts with admitting what the problem is. That said, I think that you are right that the distribution of untampered copies is a serious issue, and one that will eventually be something SC will wrestle with. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] no-keyring public
Can it not? A distributed store for salts seems possible... but then distributed keyring is also possible, is it not? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] no-keyring public
On August 24, 2013 at 1:41:27 PM, Ben Laurie (b...@links.org) wrote: On 24 August 2013 19:14, Krisztián Pintér pinte...@gmail.com wrote: 1. In your system the KDF for creating the seed to PRNG can’t be salted. nope, it can't be. Can it not? A distributed store for salts seems possible... OK, “can’t” was too strong of a word. But it appears to me that any mechanism for delivering the salts might as well just deliver the encrypted private key. And such a system would undermine the original intent (as I understand it) of the proposal. That is, if I understand the original intent it is so that the user doesn’t need to carry their (encrypted) public key with them. All they ever need to know is their password. If they need to know their password and their salt, then either (1) that salt gets distributed when they needed it, or (2) they need to carry the salt with them In either case, there is no advantage (unless I’ve missed some point) in just distributing/managing the salt over distributing/managing the encrypted private keys. Cheers, -j ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] no-keyring public
On 24 August 2013 19:55, Krisztián Pintér pinte...@gmail.com wrote: Can it not? A distributed store for salts seems possible... but then distributed keyring is also possible, is it not? Yes. Or at least cloud storage for secrets. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] no-keyring public
aha, i'm not that original after all. my attention was called to Dan Kaminsky's Phidelius too. It's very similar (as Greg Rose noted) to IBE, and thus pretty much what I did in: http://middleware.internet2.edu/pki05/proceedings/callas-conventional_ibe.pdf ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] no-keyring public
On 2013-08-25 7:58 AM, James A. Donald wrote: On 2013-08-25 2:30 AM, � wrote: hi list, i had an epiphany today, and i wonder if such a thing already exists or not. so the usual thing is to create a key pair, store the private key encripted with a password. we automatically get a two factor authentication, we have a know and a have. okay, but what if we don't want this, and we want our old password only, no keyring approach? we can do that. how about this? stretch the password with some KDF, derive a seed to a PRNG, and use the PRNG to create the the key pair. if the algorithm is fixed, it will end up with the same keypair every time. voila, no-keyring password-only public key cryptography. do you see any downsides to that, besides the obvious ones that follow from the no-keyring requirement? (slow, weak password.) has anybody done something like that already? does it have a name? Attacker applies dictionary attack. To avoid dictionary attack, use zero knowledge passphrase proof (ZKPP)to obtain passphrase authenticated key agreement with a server (for which the acronym is PAKE, not PAKA as one might expect) Server supplies a unique salt, derived from the server's secret and the user login, with the user combines with his passprhase If user has strong passphrase, server cannot guess user's secret key If user has weak passphrase, server, but not eavesdropper, can reconstruct secret key by dictionary attack. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
