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
Yes, we're looking at ways to extend the open source grant. GPL will most likely be only the first step. William - sent from my phone On Nov 28, 2013 5:14 AM, "CodesInChaos" wrote: > Have you considered a patent licence that applies to all open source > software, similar to Rogaway's OCB License 1? > > http://www.cs.ucdavis.edu/~rogaway/ocb/license1.pdf > > It has a clause that the whole software needs to be open source, not > just the library, so it's similar to GPL in that regard. > But it enables use in a wider range of open source software which > doesn't use GPL. > ___ 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" 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] 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" 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 wrote: > - Forwarded message from Gregory Maxwell - > > Date: Sun, 4 Aug 2013 23:41:57 -0700 > From: Gregory Maxwell > To: Peter Vessenes > Cc: Bitcoin Dev > Subject: Re: [Bitcoin-development] Preparing for the Cryptopocalypse > > On Sun, Aug 4, 2013 at 8:30 PM, Peter Vessenes 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=49501711&iu=/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 http://leitl.org";>leitl 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] cryptanalysis of 923-bit ECC?
Does anyone know if this attack took the expected amount of time (confirming the strength of this particular curve), or significantly less (in which case it’s something to be concerned about)? William *From:* cryptography-boun...@randombit.net [mailto: cryptography-boun...@randombit.net] *On Behalf Of *Matthew Green *Sent:* Wednesday, June 20, 2012 11:35 AM *To:* Charles Morris *Cc:* cryptography@randombit.net *Subject:* Re: [cryptography] cryptanalysis of 923-bit ECC? I'm definitely /not/ an ECC expert, but this is a pairing-friendly curve, which means it's vulnerable to a type of attack where EC group elements can be mapped into a field (using a bilinear map), then attacked using an efficient field-based solver. (Coppersmith's). NIST curves don't have this property. In fact, they're specifically chosen so that there's no efficiently-computable pairing. Moreover, it seems that this particular pairing-friendly curve is particularly tractable. The attack they used has an estimated running time of 2^53 steps. While the 'steps' here aren't directly analogous to the operations you'd use to brute-force a symmetric cryptosystem, it gives a rough estimate of the symmetric-equivalent key size. (Apologies to any real ECC experts whose work I've mangled here… :) Matt On Jun 20, 2012, at 10:59 AM, Charles Morris wrote: "NIST guidelines state that ECC keys should be twice the length of equivalent strength symmetric key algorithms." So according to NIST solving a 923b ECC is like brute-forcing a 461b bit symmetric key (I assume in a perfect cipher?). Of course there are weak keys in almost any system e.g. badly implemented RSA picking p=q I wonder if a weak-key scenario has occurred, or if this is a genuine generalized mathematical advance? Comments from ECC experts? ___ 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?
> > 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
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 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?
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
