Re: [cryptography] no-keyring public
On 25-08-2013 13:38, Alexander Klimov wrote: There was a ECC program from the previous century that worked as you described: the private key was derived solely from the user password. Unfortunately, I cannot recall its name (and I suspect it already vanished from the net since it was not secure due to its use of EC over binary composite field, Weil descent attack), but I guess someone here remembers its name, since at that time it was a rare example of ECC software. The name was Pegwit: http://www.george-barwood.pwp.blueyonder.co.uk/hp/v8/pegwit.htm ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] no-keyring public
On Sun, Aug 25, 2013 at 08:13:51AM -0400, Matthew Orgass wrote: On 2013-08-25 alser...@inbox.ru wrote: On Sat, 24 Aug 2013, Krisztián Pintér wrote: has anybody done something like that already? does it have a name? There was a ECC program from the previous century that worked as you described: the private key was derived solely from the user password. Seccure: http://point-at-infinity.org/seccure/ i 3 seccure. the lack of a good kdf was easily fixed with scrypt. It could even do ECDH. I wish there were more simple command line crypto utilities. good memories. so i just added ECDH also to my new tool: https://github.com/stef/pbp which is based on libsodium, based on nacl. also i created a new wrapper for python, pysodium: https://github.com/stef/pysodium hope you enjoy and play around with simple command line crypto utilities. -- pgp: https://www.ctrlc.hu/~stef/stef.gpg pgp fp: FD52 DABD 5224 7F9C 63C6 3C12 FC97 D29F CA05 57EF otr fp: https://www.ctrlc.hu/~stef/otr.txt ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] no-keyring public
On Sat, 24 Aug 2013, Krisztián Pintér wrote: has anybody done something like that already? does it have a name? There was a ECC program from the previous century that worked as you described: the private key was derived solely from the user password. Unfortunately, I cannot recall its name (and I suspect it already vanished from the net since it was not secure due to its use of EC over binary composite field, Weil descent attack), but I guess someone here remembers its name, since at that time it was a rare example of ECC software. Btw, this memorable private key technique has nothing to do with IBE, since no trusted third party is required. -- Regards, ASK___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] no-keyring public
On 2013-08-25 alser...@inbox.ru wrote: On Sat, 24 Aug 2013, Krisztián Pintér wrote: has anybody done something like that already? does it have a name? There was a ECC program from the previous century that worked as you described: the private key was derived solely from the user password. Seccure: http://point-at-infinity.org/seccure/ It doesn't do any key stretching plus has a number of implementation problems, but I used it a little for backups until it corrupted some and I found the scrypt utility. Seccure seemed nice from a usability perspective other than that you couldn't quite decrypt and pipe the result to less reliably. There were command line arguments for curve and MAC length that you just had to get right or it didn't work. It could even do ECDH. I wish there were more simple command line crypto utilities. -Matt___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] no-keyring public
Bitcoin Brainwallet software creates ECDSA keys that you can use for multiple purposes, not only for Bitcoin. A link to Phidelius, which was previously mentioned: http://dankaminsky.com/2012/01/03/phidelius/ --- I would like to see some standardized hierarchial deterministic scheme to generate various types of keys from a master password. Here's my idea for how you could do it in a reasonably secure way (assuming the master password is chosen in a secure manner and used in a secure manner); First of all you have a master password, of course. Ideally it should be generated randomly (represented to you as words, diceware style), but arbitary user input is accepted. First you run scrypt (or bcrypt?) on the master password, salted with a standard string, generating a master seed. From this you can generate several different outputs. One of them is used to generate a number of master keys (RSA, ECDSA, or whatever else you want) through scrypt with another specific salt from that master seed. To make sure it's deterministic you use specific algorithms with predefined parameters. For example ECDSA with the parameters that Bitcoin uses (we can take this code straight from a Bitcoin brainwallet generator), or some specific parameters for RSA 4096 bits, or even a specific Lamport scheme implementation. Each algorithm + parameter combination would be referred to with it's own specific name. The master seed is also used to generate a number of temporary seeds (with scrypt on the master seed plus a special string plus a counter, and you need to remember this counter once you've started to revoke and replace old temporary seeds). The temporary seeds are presented to you encoded as a series of words so you do not need to use your master password everywhere. They are then used to create a set of temporary keys in the same way. You can use your master key(s) to revoke temporary keys. How long you should use each temporary seed and it's keys is up to you - for example you could use each for one year, or maybe even just for one day. When you enter your master password the client generates a bunch of these keys and signs the subkeys with the master key(s), allowing you to publish all those signatures at once, and them memorize the first temporary seed. It also generates a revocation signature for the master key(s) themselves that you can publish if/when needed. Then you can go on using those temporary keys, and be fairly calm about using the temporary keys as every key is revokable (although revocation notifications don't always travel fast, which can be a problem...). Of course this fails catastrophically if you use bad passwords or if they leak, so I probably would not recommend this for anybody other than a person who do not have long-term access to any reliable form of storage, for example a person who are forced to continously ditch their old electronics and trash it and switch to new temporary devices. If you can generate AND remember strong passwords, then it would work fine. But the problem is that most people fails at one or both of those two, even though you CAN learn to do it. 2013/8/25 Alexander Klimov alser...@inbox.ru: On Sat, 24 Aug 2013, Krisztián Pintér wrote: has anybody done something like that already? does it have a name? There was a ECC program from the previous century that worked as you described: the private key was derived solely from the user password. Unfortunately, I cannot recall its name (and I suspect it already vanished from the net since it was not secure due to its use of EC over binary composite field, Weil descent attack), but I guess someone here remembers its name, since at that time it was a rare example of ECC software. Btw, this memorable private key technique has nothing to do with IBE, since no trusted third party is required. -- Regards, ASK ___ 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] 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
