Re: [cryptography] [cryptome] question
At 11:01 AM 1/3/2014, you wrote: Friends, Given the fact that Levison states: This experience has taught me one very important lesson: without congressional action or a strong judicial precedent, I would _strongly_ recommend against anyone trusting their private data to a company with physical ties to the United States. Sincerely, Ladar Levison Owner and Operator, Lavabit LLC which normal website hoster friends here could recommend in which countries? Iceland may be the only one, and that may be short-lived before it is expropriated by open and/or secret undermining. Or it is likely a honey pot like so many other dropboxes, pastes, leak sites, privacy and FOI initiatives. Big business now offering ways to avoid boogie-spies, aka cybersecurity, by govs, coms, edus, orgs, sec experts. All other countries are more intrusive than the US, and all are becoming even more intrusive thanks to the booming industry of intrusive hardware, software, programs, staffing, contracting, higher education, co-optation of comsec experts, freedom of information organizations, religious institutions and many others who are benefiting from data mining of their supporters by selling information either directly or through second and third parties, in many cases, those sales are occurring by system administrators, temporary employees and volunteers, informants, ex-employees and volunteers, Web sites, and mail lists, like this one, news outlets, leak sites, conference organizers, educational institutions and innumerable others are gathering and selling data as fast as possible before legal restrictions are enacted. These private spying entrepreneurs are fearful that the crackdown on official spies will spill over into their opportunism, their windfall, their golden goose of data exploitation. Ubiquitous log files, ostensibly required for system administration, are the gold mines which implicate every sneak-thief operator of public, private, governmental, NGO, commercial venues. The USA, UK and Sweden are out and so are all EU countries. Please let me have some good recommendations with hoster and country you would choose if you had to transfer a website and its database and mailing list capabilities. Thanks IHW ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [cryptome] question
On 1/3/2014 11:36 AM, John Young wrote: At 11:01 AM 1/3/2014, you wrote: Friends, Given the fact that Levison states: This experience has taught me one very important lesson: without congressional action or a strong judicial precedent, I would _strongly_ recommend against anyone trusting their private data to a company with physical ties to the United States. Sincerely, Ladar Levison Owner and Operator, Lavabit LLC which normal website hoster friends here could recommend in which countries? Iceland may be the only one, and that may be short-lived before it is expropriated by open and/or secret undermining. Or it is likely a honey pot like so many other dropboxes, pastes, leak sites, privacy and FOI initiatives. Big business now offering ways to avoid boogie-spies, aka cybersecurity, by govs, coms, edus, orgs, sec experts. All other countries are more intrusive than the US, and all are becoming even more intrusive thanks to the booming industry of intrusive hardware, software, programs, staffing, contracting, higher education, co-optation of comsec experts, freedom of information organizations, religious institutions and many others who are benefiting from data mining of their supporters by selling information either directly or through second and third parties, in many cases, those sales are occurring by system administrators, temporary employees and volunteers, informants, ex-employees and volunteers, Web sites, and mail lists, like this one, news outlets, leak sites, conference organizers, educational institutions and innumerable others are gathering and selling data as fast as possible before legal restrictions are enacted. These private spying entrepreneurs are fearful that the crackdown on official spies will spill over into their opportunism, their windfall, their golden goose of data exploitation. Ubiquitous log files, ostensibly required for system administration, are the gold mines which implicate every sneak-thief operator of public, private, governmental, NGO, commercial venues. The USA, UK and Sweden are out and so are all EU countries. Please let me have some good recommendations with hoster and country you would choose if you had to transfer a website and its database and mailing list capabilities. Thanks IHW ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography I'm sorry, but is this a sick joke? Why are we beeing advised not to trust the U.S? Did I read this wrong? -- Kevin ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] pie in sky suites - long lived public key pairs for persistent identity
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, ___ 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
