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
Re: [cryptography] ntru-crypto - Open Source NTRU Public Key Cryptography Algorithm and Reference Code
We’re getting a lot of feedback that this isn’t clear, and we’ll make sure it is clarified. Also, it’s not clear that this grant is meant to be irrevocable; we’ll fix that too. William *From:* William Whyte [mailto:wwh...@securityinnovation.com] *Sent:* Wednesday, November 27, 2013 6:40 PM *To:* Lars Luthman *Cc:* Crypto discussion list *Subject:* Re: [cryptography] ntru-crypto - Open Source NTRU Public Key Cryptography Algorithm and Reference Code It's meant to be 2 and later. Sorry if this isn't clear, we'll revise the license text. William - sent from my phone On Nov 27, 2013 6:28 PM, Lars Luthman m...@larsluthman.net wrote: So the news is that it can be used for GPL software without patent issues? If so that's nice, but the various documents are a bit confusing: https://github.com/NTRUOpenSourceProject/ntru-crypto Is NTRU Patented? Yes. The patents will still be enforced but may be used under the GPL, i.e. under the condition that any work that uses them is also made available under the GPL. The patents and the code implementations are also available under standard commercial terms. Great! https://github.com/NTRUOpenSourceProject/ntru-crypto/blob/master/PATENTS.md GPL NTRU cryptographic patents may be used as long as the user adheres to version two (2) of the GPL License. For details please refer to COPYING-2.txt included in this distribution. The GPLv2 license may also be found on the gnu.org website at: (http://www.gnu.org/licenses/gpl-2.0.html) ...but only GPLv2? https://github.com/NTRUOpenSourceProject/ntru-crypto/blob/master/COPYRIGHT.md Copyright (C) 2009-2013 Security Innovation This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. And here it says GPLv2 or any later version, which includes GPLv3, which has the text about automatic patent licensing. Both GPLv2 and GPLv3 are included in the repository as COPYING-2.txt and COPYING-3.txt, and the source files have copyright notices that say GPLv2 or later. Does anyone know which it is? GPLv2 or later, or just GPLv2? --ll ___ 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] [Bitcoin-development] Preparing for the Cryptopocalypse
Just to be clear, NIST haven't endorsed NTRU for use, but they did speak favourably of it in a report on quantum-secure crypto. William On Mon, Aug 5, 2013 at 7:04 AM, Eugen Leitl eu...@leitl.org wrote: - Forwarded message from Gregory Maxwell gmaxw...@gmail.com - Date: Sun, 4 Aug 2013 23:41:57 -0700 From: Gregory Maxwell gmaxw...@gmail.com To: Peter Vessenes pe...@coinlab.com Cc: Bitcoin Dev bitcoin-developm...@lists.sourceforge.net Subject: Re: [Bitcoin-development] Preparing for the Cryptopocalypse On Sun, Aug 4, 2013 at 8:30 PM, Peter Vessenes pe...@coinlab.com wrote: I studied with Jeffrey Hoffstein at Brown, one of the creators of NTRU. He told me recently NTRU, which is lattice based, is one of the few (only?) NIST-recommended QC-resistant algorithms. Lamport signatures (and merkle tree variants that allow reuse) are simpler, faster, trivially implemented, and intuitively secure under both classical and quantum computation (plus unlikely some proposed QC strong techniques they're patent clear). They happen to be the only digital signature scheme that you really can successfully explain to grandma (even for values of grandma which are not cryptographers). They have poor space/bandwidth usage properties, which is one reason why Bitcoin doesn't use them today, but as far as I know the same is so for all post-QC schemes. Though I question the validity of the claim that ECC is so much more secure than RSA (with appropriate keysizes). The problems are intimately related, but under the best understanding ECC (with suitable parameters) ends up being the maximally hard case of that problem class. I do sometimes worry about breakthroughs that give index-calculus level performance for general elliptic curves, this still wouldn't leave it any weaker than RSA but ECC is typically used with smaller keys. -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list bitcoin-developm...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ 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] Proving knowledge of a message with a given SHA-1 without disclosing it?
You can obviously prove it in the case where Alice claims she knows SHA-1(SHA-1(m)), which seems to be the same claim. William -Original Message- From: cryptography-boun...@randombit.net [mailto:cryptography- boun...@randombit.net] On Behalf Of Francois Grieu Sent: Wednesday, February 01, 2012 4:49 AM To: cryptography@randombit.net Subject: [cryptography] Proving knowledge of a message with a given SHA-1 without disclosing it? Alice discloses a 160-bit value h and claims that she (or parties/devices she has access to) knows a message m with h=SHA-1(m). Can she convince Bob of her claim using some protocol, without letting Bob find m, and without a third party or device that Bob trusts? At a Crypto'98 rump session, Hal Finney made a 7-minutes presentation A zero-knowledge proof of possession of a pre-image of a SHA-1 hash claiming a feasible protocol for this. http://video.google.com/videoplay?docid=-5745972992365920864 This talk mentions using the protocol in the Crypto'98 paper of Ronald Cramer and Ivan B. Damgård: Zero-Knowledge Proofs for Finite Field Arithmetic or: Can Zero-Knowledge be for Free? http://www.springerlink.com/content/0l4734h77615u161/ ftp://ftp.inf.ethz.ch/pub/crypto/publications/CraDam98.pdf http://www.brics.dk/RS/97/27/BRICS-RS-97-27.pdf The talk does not give much details, and I failed to locate any article with a similar claim. I would find that result truly remarkable, and it is against my intuition. Any info on the Hal Finney protocol, or a protocol giving a similar result, or the (in)feasibility of such a protocol? TIA, Francois Grieu ___ 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] How are expired code-signing certs revoked?
Cute scenario! I would say that you shouldn't *install* signed software after the signing cert expires, but if you installed it before expiry it's still safe to use it. In general, you shouldn't act based on a certificate if you don't know it's trustworthy (obviously), but the action in question here is installing the software, not running it. Cheers, William -Original Message- From: cryptography-boun...@randombit.net [mailto:cryptography-boun...@randombit.net] On Behalf Of Peter Gutmann Sent: Wednesday, December 07, 2011 7:02 AM To: cryptography@randombit.net Subject: [cryptography] How are expired code-signing certs revoked? Consider the following scenario: 1. Attackers steal a code-signing key and use it to sign malware. 2. The certificate for the stolen key expires. 3. Malware signed with the key turns up. Since the signature is timestamped to allow it to still validate after the original cert expires, it'll be regarded as valid. Since the cert has now expired, it won't be present in the CRL, or if it was present it'll be removed (this is standard practice to manage CRL sizes). How do you invalidate such a signature? Peter. ___ 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] How are expired code-signing certs revoked?
Well, I think the theoretically correct answer is that you *should*... these days all the installers can be available online, after all. William -Original Message- From: Peter Gutmann [mailto:pgut...@cs.auckland.ac.nz] Sent: Wednesday, December 07, 2011 9:21 AM To: cryptography@randombit.net; pgut...@cs.auckland.ac.nz; wwh...@securityinnovation.com Subject: RE: [cryptography] How are expired code-signing certs revoked? William Whyte wwh...@securityinnovation.com writes: I would say that you shouldn't *install* signed software after the signing cert expires, but if you installed it before expiry it's still safe to use it. That wouldn't work, consider the untold numbers of install CDs shipped with anything that you could think of conneting to a PC at some point (your shiny new digital camera, your electric toothbrush, ...). These are often extremely out-of-date, but you can't block the install just because the cert has expired. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] How are expired code-signing certs revoked?
But really, I think that code signing is a great thing, it's just being done wrong because some people seem to think that spooky action at a distance works with bits. The question at hand is this: what is the meaning of expiration or revocation of a code-signing certificate? That I can't sign new code? That only affects the good guys. That I can't install code that was really signed before the operative date? How can I tell when it was actually signed? That I can't rely on it after the specified date? That would require continual resigning of code. That seems to be the best answer, but the practical difficulties are immense. I would say that you shouldn't install code signed with an expired certificate, but you can continue to use code you've already installed after the certificate expires. That requires occasional resigning, rather than continual. Revocation is a different issue; it seems like it should require either spooky action at a distance or TTP timestamping (as ianG discussed earlier). In the absence of timestamping, if a code signing cert is revoked, the most sensible thing to do is uninstall any software signed with that cert. This obviously means that even expired certs need to appear on a CRL, which raises the question of whether it's worth expiring them. I think it probably is worth it because (a) it raises the possibility that one cert's worth of software could be withdrawn without requiring all software from that vendor to be compromised, although at that point you're into marginal gains in very hypothetical situations; and (b) it makes going out of business cleaner and doesn't leave too many still-valid certs floating around. William ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
