Re: [cryptography] pie in sky suites - long lived public key pairs for persistent identity
On Fri, Jan 3, 2014 at 11:42 AM, coderman coder...@gmail.com wrote: use case is long term (decade+) identity ... key signs working keys tuned for speed with limited secret life span (month+). i should have better clarified intent: - long term keys are offline, otherwise better protected (for arbitrary degrees of beyond the everyday level). thwarting active attacks or chosen input attacks is explicitly intended. - long term keys can be large, or slow, or demand elevated protections and blinding, or other mechanisms which aggravate to point of disabling or calling to costly with respect to the working / short term keys. applying all reasonable protections is specifically intended. - long term keys may be M of N threshold schemes for group or ceremony based attestations for other long term keys, working keys, or secure identifiers in general. said another way, long term keys are specifically intended as trust anchors in public key systems of various types. thanks all for the input that followed; i appreciate it! best regards, ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] pie in sky suites - long lived public key pairs for persistent identity
On 3/01/14 22:42 PM, coderman wrote: use case is long term (decade+) identity rather than privacy or session authorization. Long term identity is not a concept in a vacuum. Identity in software business always relates to other people, your identity is like the sum of the thoughts that *others have about you* unlike psychology where identity is a concept of how you think about yourself. So you have to consider (a) everyone else and (b) how everyone else interacts with you. Which in today's world is pointing to the phone. If we're talking the identity on the phone, we're now talking about 2 or more things, horizontally: an app by itself, or an app that integrates vertically with the telco (SIM card). We can also bifurcate vertically with Apple v. Android, and also-rans. The point being that identity of the future is constrained to the platform that everyone lives on. The western/past was your laptop and PGP and online banking. The all-world/future is the phone and mPesa style mobile money and apps like SnapChat. The phone is a really sucky platform for security purposes. The end conclusion of this argument is that ... it doesn't matter much what strength/type key you're using because you have to deal with the platform. As an example. In my business, we have money on phones, including shared accounts and treasurer management and other stuff. This gets hairy if say /the treasurer loses her phone/. This is a real, live, every day issue. What to do? (skipping long analysis)... we have to be able to recover the entire app onto a new phone and carry on as if nothing had happened. To do this, we have to migrate the swamp of server escrow (cryptocloud! got it sorta working last night) and encryption against servers and 4 digit pins and finger swipes and cooperative arrangements with people who today are your most trusted friends and tomorrow have stolen all your money. See where this is going? The conclusion is, it doesn't matter a damn what strength key you use. In practice, we use what tickles us as geeks, and what works well with our software design. eternity key signs working keys tuned for speed with limited secret life span (month+). working keys are used for secret exchange and any other temporal purpose. you may use any algorithms desired; what do you pick? Curve3617+NTRU eternity key Curve25519 working keys ChaCha20+Poly1305-AES for sym./mac ? I'm using RSA1024/AES128/SHA1-HMAC at the moment, I could use RSA512 and I'd be within my analysed threat model and designed security model. I'll switch over at some stage to CurveLatest/ChaCha20+Poly1305 ... but it won't make a jot of difference to my identity. I'll do it coz it's cool. this assumes key agility by signing working keys with all eternity keys, and promoting un-broken suites to working suites as needed. you cannot retro-actively add new suites to eternity keys; these must be selected and generated extremely conservatively. other questions: - would you include another public key crypto system with the above? (if so, why?) No. RSA then EC is what I'll do. I don't know about NTRU, but I'm the guy who always says less is best. - does GGH signature scheme avoid patent mine fields? (like NTRU patents) - is it true that NSA does not use any public key scheme, nor AES, for long term secrets? Now that is a question! Yes, let's hear more about their use of Public Key [0]. This is now a validated issue, because Suite B and EC is under a cloud by the NSA's actions. Anyone? - are you relieved NSA has only a modest effort aimed at keeping an eye on quantum cryptanalysis efforts in academia and other nations? lol... What was also funny was that paper had a lot of TS over it. Nice to know that these guys are carefully covering up the bleeding obvious. Maybe that's why the newspaper released it over New Year's Day, for humour. iang [0] http://financialcryptography.com/mt/archives/001451.html ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] pie in sky suites - long lived public key pairs for persistent identity
In an unsigned posting, it is written: On 3/01/14 22:42 PM, coderman wrote: use case is long term (decade+) identity rather than privacy or session authorization. Long term identity is not a concept in a vacuum. Identity in software business always relates to other people, your identity is like the sum of the thoughts that *others have about you* unlike psychology where identity is a concept of how you think about yourself. There's no escape from identity being founded on how one thinks of oneself. Cogito ergo sum. There's only one individual in the universe who is qualified to know I am Alice, and it ain't you or me, it's Alice. A good actress might convince others that she is Alice, but Alice knows better, and Alice is the only individual who can know better authoritatively. But there is a way for Alice to identify herself to others, and it's public key cryptography. Alice can arrange that only she knows the private key associated with a certain public key. Alice can further arrange that the sum of the thoughts that others have about her can be founded only on expressions which are signed by her private key. She does this by signing all of her expressions and publicly declaring that any expression purporting to be from her but not signed by her private key is a forgery. On the Internet, your identity is your private key. If you have no private key, you have no Internet identity. -- -- StealthMonger stealthmon...@nym.mixmin.net who herewith declares that any expression purporting to be from Stealthmonger but not signed with the following key is a forgery. Key: mailto:stealthsu...@nym.mixmin.net?subject=send%20stealthmonger-key pgpZUtscLXxuc.pgp Description: PGP signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] pie in sky suites - long lived public key pairs for persistent identity
On Sat, Jan 4, 2014 at 4:26 AM, ianG i...@iang.org wrote: On 3/01/14 22:42 PM, coderman wrote: use case is long term (decade+) identity rather than privacy or session authorization. ... Which in today's world is pointing to the phone. If we're talking the identity on the phone, we're now talking about 2 or more things, horizontally: an app by itself, or an app that integrates vertically with the telco (SIM card). We can also bifurcate vertically with Apple v. Android, and also-rans. That may be moving to a single Yubikey. See Google U2F (Gnubby): Overview for Partners, https://docs.google.com/presentation/d/16mB3Nptab1i4-IlFbn6vfkWYk-ozN6j3-fr7JL8XVyA/ (thanks AR). Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] pie in sky suites - long lived public key pairs for persistent identity
On Fri, Jan 3, 2014 at 1:42 PM, coderman coder...@gmail.com wrote: - are you relieved NSA has only a modest effort aimed at keeping an eye on quantum cryptanalysis efforts in academia and other nations? But clearly you must not be. If you want to assume quantum cryptanalysis then you should only use ECDH when you can protect the public keys with something like NTRU (that is, if you must exchange public keys over an insecure network at all) that we think is impervious to quantum cryptanalysis. Once you have that then IMO the DJB curves look pretty good. Once you have session keys you can use AES in any reasonable AEAD mode (by generic composition with HMAC, with SHA-3, GCM, whatever) if you like (and I would, provided the implementation is constant-time). Why do you need working keys? Mostly for session management reasons (traffic analysis alert!). If you can avoid the need for distinguishing between long-term and working keys and you can physically distribute public ECDH keys and then keep them secret then you don't even need NTRU. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] pie in sky suites - long lived public key pairs for persistent identity
Den 3 jan 2014 20:42 skrev coderman coder...@gmail.com: use case is long term (decade+) identity rather than privacy or session authorization. eternity key signs working keys tuned for speed with limited secret life span (month+). working keys are used for secret exchange and any other temporal purpose. you may use any algorithms desired; what do you pick? Curve3617+NTRU eternity key Curve25519 working keys ChaCha20+Poly1305-AES for sym./mac ? this assumes key agility by signing working keys with all eternity keys, and promoting un-broken suites to working suites as needed. you cannot retro-actively add new suites to eternity keys; these must be selected and generated extremely conservatively. other questions: - would you include another public key crypto system with the above? (if so, why?) - does GGH signature scheme avoid patent mine fields? (like NTRU patents) - is it true that NSA does not use any public key scheme, nor AES, for long term secrets? - are you relieved NSA has only a modest effort aimed at keeping an eye on quantum cryptanalysis efforts in academia and other nations? best regards First of all I'd have a lifetime masterkey intended to never be touched (meant for permanent secure storage) at the top, that signs the long-term subkey. That means that if your long-term key (which you very likely WILL access a few dozen to hundred times at least) is compromised, you can replace it. My process would be to generate a lifetime masterkey + long-term subkey + working key, where each long-term key signs new working keys (and revokes them) as well as new long-term keys, and where the masterkey can revoke and replace all other keys. Note that NTRU now has a pledge that it is free for all open source software (it's even officially on github with that license). They have a long list of approved licenses where usage is all free. - Sent from my phone ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] pie in sky suites - long lived public key pairs for persistent identity
On Fri, Jan 03, 2014 at 11:42:47AM -0800, coderman wrote: use case is long term (decade+) identity rather than privacy or session authorization. eternity key signs working keys tuned for speed with limited secret life span (month+). working keys are used for secret exchange and any other temporal purpose. you may use any algorithms desired; what do you pick? Curve3617+NTRU eternity key Curve25519 working keys ChaCha20+Poly1305-AES for sym./mac Why can we only pick one? In the context of stuff like email the overhead of n-of-m multisignature isn't a big deal. Heck, even in the context of Bitcoin where transactions have a cost per KB in the order of $0.10 to $1 n-of-m multisignature is catching on as a way to protect funds from theft. Why should digital signatures be any different? -- 'peter'[:-1]@petertodd.org 000251d8c6bb4f73d2f68e359fe143dfd3645374a4d26d09388c signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] pie in sky suites - long lived public key pairs for persistent identity
I agree, multisignatures seem prudent. So does multiple public key encryption algorithms for symmetric key exchange. Why risk a breakthrough against one? Cheers, William -Original Message- From: cryptography [mailto:cryptography-boun...@randombit.net] On Behalf Of Peter Todd Sent: Friday, January 03, 2014 4:05 PM To: coderman Cc: cpunks; Discussion of cryptography and related Subject: Re: [cryptography] pie in sky suites - long lived public key pairs for persistent identity On Fri, Jan 03, 2014 at 11:42:47AM -0800, coderman wrote: use case is long term (decade+) identity rather than privacy or session authorization. eternity key signs working keys tuned for speed with limited secret life span (month+). working keys are used for secret exchange and any other temporal purpose. you may use any algorithms desired; what do you pick? Curve3617+NTRU eternity key Curve25519 working keys ChaCha20+Poly1305-AES for sym./mac Why can we only pick one? In the context of stuff like email the overhead of n-of-m multisignature isn't a big deal. Heck, even in the context of Bitcoin where transactions have a cost per KB in the order of $0.10 to $1 n-of-m multisignature is catching on as a way to protect funds from theft. Why should digital signatures be any different? -- 'peter'[:-1]@petertodd.org 000251d8c6bb4f73d2f68e359fe143dfd3645374a4d26d09388c ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
