Hi Peter,
On 30/09/13 23:31 PM, Peter Fairbrother wrote:
On 26/09/13 07:52, ianG wrote:
On 26/09/13 02:24 AM, Peter Fairbrother wrote:
On 25/09/13 17:17, ianG wrote:
On 24/09/13 19:23 PM, Kelly John Rose wrote:
I have always approached that no encryption is better than bad
encryption,
On 30 September 2013 23:35, John Kelsey crypto@gmail.com wrote:
If there is a weak curve class of greater than about 2^{80} that NSA knew
about 15 years ago and were sure nobody were ever going to find that weak
curve class and exploit it to break classified communications protected by
Hi,
On 01/10/2013 19:39, Peter Fairbrother wrote:
Also, the method by which the generators (and thus the actual groups in
use, not the curves) were chosen is unclear.
If we're talking about the NIST curves over prime fields, they all have cofactor
1, so the actual group used is E(F_p), the
On Oct 2, 2013, at 9:54 AM, Paul Crowley p...@ciphergoth.org wrote:
On 30 September 2013 23:35, John Kelsey crypto@gmail.com wrote:
If there is a weak curve class of greater than about 2^{80} that NSA knew
about 15 years ago and were sure nobody were ever going to find that weak
curve
2. okt. 2013 kl. 16:59 skrev John Kelsey crypto@gmail.com:
On Oct 2, 2013, at 9:54 AM, Paul Crowley p...@ciphergoth.org wrote:
On 30 September 2013 23:35, John Kelsey crypto@gmail.com wrote:
If there is a weak curve class of greater than about 2^{80} that NSA knew
about 15 years
On 30 September 2013 23:24, John Kelsey crypto@gmail.com wrote:
Maybe you should check your code first? A couple nist people verified
that the curves were generated by the described process when the questions
about the curves first came out.
If you don't quote the message you're
On 28/09/13 22:06 PM, ianG wrote:
On 27/09/13 18:23 PM, Phillip Hallam-Baker wrote:
Problem with the NSA is that its Jekyll and Hyde. There is the good side
trying to improve security and the dark side trying to break it. Which
side did the push for EC come from?
What's in Suite A? Will
1. okt. 2013 kl. 02:00 skrev James A. Donald jam...@echeque.com:
On 2013-10-01 08:24, John Kelsey wrote:
Maybe you should check your code first? A couple nist people verified that
the curves were generated by the described process when the questions about
the curves first came out.
And
On 01/10/13 08:49, Kristian Gjøsteen wrote:
1. okt. 2013 kl. 02:00 skrev James A. Donald jam...@echeque.com:
On 2013-10-01 08:24, John Kelsey wrote:
Maybe you should check your code first? A couple nist people verified that the
curves were generated by the described process when the
On Sun, Sep 29, 2013 at 9:15 PM, Viktor Dukhovni
cryptogra...@dukhovni.org wrote:
On Mon, Sep 30, 2013 at 10:07:14AM +1000, James A. Donald wrote:
Therefore, everyone should use Curve25519, which we have every
reason to believe is unbreakable.
Superceded by the improved Curve1174.
Hardly.
James == James A Donald jam...@echeque.com writes:
Gregory Maxwell on the Tor-talk list has found that NIST approved
curves, which is to say NSA approved curves, were not generated by the
claimed procedure, which is a very strong indication that if you use
NIST curves in your cryptography,
On 26/09/13 07:52, ianG wrote:
On 26/09/13 02:24 AM, Peter Fairbrother wrote:
On 25/09/13 17:17, ianG wrote:
On 24/09/13 19:23 PM, Kelly John Rose wrote:
I have always approached that no encryption is better than bad
encryption, otherwise the end user will feel more secure than they
should
Having read the mail you linked to, it doesn't say the curves weren't generated
according to the claimed procedure. Instead, it repeats Dan Bernstein's
comment that the seed looks random, and that this would have allowed NSA to
generate lots of curves till they found a bad one.
it looks to
On 2013-10-01 08:24, John Kelsey wrote:
Maybe you should check your code first? A couple nist people verified that the
curves were generated by the described process when the questions about the
curves first came out.
And a non NIST person verified that the curves were /not/ generated by
On 2013-10-01 08:35, John Kelsey wrote:
Having read the mail you linked to, it doesn't say the curves weren't generated
according to the claimed procedure. Instead, it repeats Dan Bernstein's
comment that the seed looks random, and that this would have allowed NSA to
generate lots of curves
On Sep 28, 2013, at 3:06 PM, ianG wrote:
Problem with the NSA is that its Jekyll and Hyde. There is the good side
trying to improve security and the dark side trying to break it. Which
side did the push for EC come from?
What's in Suite A? Will probably illuminate that question...
The actual
2013/9/29 James A. Donald jam...@echeque.com
(..) fact, they are not provably random, selected (...)
fixed that for you
It seems obvious that blatant lying about qualities of procedures must have
some malignant intention, yet ignorance is as good an explanation. I don't
think lying the other
On 2013-09-30 03:14, Lodewijk andré de la porte wrote:
2013/9/29 James A. Donald jam...@echeque.com
mailto:jam...@echeque.com
(..) fact, they are not provably random, selected (...)
fixed that for you
It seems obvious that blatant lying about qualities of procedures must
have some
Gregory Maxwell on the Tor-talk list has found that NIST approved
curves, which is to say NSA approved curves, were not generated by the
claimed procedure, which is a very strong indication that if you use
NIST curves in your cryptography, NSA can read your encrypted data.
As computing power
On Mon, Sep 30, 2013 at 10:07:14AM +1000, James A. Donald wrote:
Therefore, everyone should use Curve25519, which we have every
reason to believe is unbreakable.
Superceded by the improved Curve1174.
http://cr.yp.to/elligator/elligator-20130527.pdf
--
Viktor.
And the problem appears to be compounded by dofus legacy implementations
that don't support PFS greater than 1024 bits. This comes from a
misunderstanding that DH keysizes only need to be half the RSA length.
So to go above 1024 bits PFS we have to either
1) Wait for all the servers to
On Fri, Sep 27, 2013 at 3:59 AM, John Gilmore g...@toad.com wrote:
And the problem appears to be compounded by dofus legacy implementations
that don't support PFS greater than 1024 bits. This comes from a
misunderstanding that DH keysizes only need to be half the RSA length.
So to go
On Fri, Sep 27, 2013 at 11:23:27AM -0400, Phillip Hallam-Baker wrote:
Actually, it turns out that the problem is that the client croaks if the
server tries to use a key size that is bigger than it can handle. Which
means that there is no practical way to address it server side within the
On 27/09/13 18:23 PM, Phillip Hallam-Baker wrote:
Problem with the NSA is that its Jekyll and Hyde. There is the good side
trying to improve security and the dark side trying to break it. Which
side did the push for EC come from?
What's in Suite A? Will probably illuminate that question...
On 2013-09-28 01:23, Phillip Hallam-Baker wrote:
Most cryptolibraries have a hard coded limit at 4096 bits and there
are diminishing returns to going above 2048. Going from 4096 to 8192
bits only increases the work factor by a very small amount and they
are really slow which means we end up
On 25/09/13 17:17, ianG wrote:
On 24/09/13 19:23 PM, Kelly John Rose wrote:
I have always approached that no encryption is better than bad
encryption, otherwise the end user will feel more secure than they
should and is more likely to share information or data they should not
be on that line.
On 26/09/13 02:24 AM, Peter Fairbrother wrote:
On 25/09/13 17:17, ianG wrote:
On 24/09/13 19:23 PM, Kelly John Rose wrote:
I have always approached that no encryption is better than bad
encryption, otherwise the end user will feel more secure than they
should and is more likely to share
Hi,
On 09/23/2013 10:47 AM, Peter Gutmann wrote:
I'm inclined to agree with you, but you might be interested/horrified in the
1024 bits is enough for anyone debate currently unfolding on the TLS list:
That's rather misrepresenting the situation. It's a debate between two
groups, the
On Sun, Sep 22, 2013 at 2:00 PM, Stephen Farrell
stephen.farr...@cs.tcd.iewrote:
On 09/22/2013 01:07 AM, Patrick Pelletier wrote:
1024 bits is enough for anyone
That's a mischaracterisation I think. Some folks (incl. me)
have said that 1024 DHE is arguably better that no PFS and
if
On 24/09/13 19:23 PM, Kelly John Rose wrote:
I have always approached that no encryption is better than bad
encryption, otherwise the end user will feel more secure than they
should and is more likely to share information or data they should not
be on that line.
The trap of a false sense of
Stephen Farrell stephen.farr...@cs.tcd.ie writes:
That's a mischaracterisation I think. Some folks (incl. me) have said that
1024 DHE is arguably better that no PFS and if current deployments mean we
can't ubiquitously do better, then we should recommend that as an option,
while at the same time
Peter Fairbrother zenadsl6...@zen.co.uk writes:
On 24/09/13 05:27, Peter Gutmann wrote:
Peter Fairbrother zenadsl6...@zen.co.uk writes:
If you just want a down-and-dirty 2048-bit FS solution which will work
today,
why not just have the websites sign a new RSA-2048 sub-certificate every
day?
On Sat, Sep 21, 2013 at 05:07:02PM -0700, Patrick Pelletier wrote:
and there was a similar discussion on the OpenSSL list recently,
with GnuTLS getting blamed for using the ECRYPT recommendations
rather than 1024:
http://www.mail-archive.com/openssl-users@openssl.org/msg71899.html
GnuTLS
On 09/22/2013 01:07 AM, Patrick Pelletier wrote:
1024 bits is enough for anyone
That's a mischaracterisation I think. Some folks (incl. me)
have said that 1024 DHE is arguably better that no PFS and
if current deployments mean we can't ubiquitously do better,
then we should recommend that as
On 9/21/13 at 5:07 PM, c...@funwithsoftware.org (Patrick
Pelletier) wrote:
I'm inclined to agree with you, but you might be
interested/horrified in the 1024 bits is enough for anyone
debate currently unfolding on the TLS list:
http://www.ietf.org/mail-archive/web/tls/current/msg10009.html
Patrick Pelletier c...@funwithsoftware.org writes:
I'm inclined to agree with you, but you might be interested/horrified in the
1024 bits is enough for anyone debate currently unfolding on the TLS list:
That's rather misrepresenting the situation. It's a debate between two
groups, the security
On 23/09/13 09:47, Peter Gutmann wrote:
Patrick Pelletier c...@funwithsoftware.org writes:
I'm inclined to agree with you, but you might be interested/horrified in the
1024 bits is enough for anyone debate currently unfolding on the TLS list:
That's rather misrepresenting the situation.
Patrick == Patrick Pelletier c...@funwithsoftware.org writes:
On 9/14/13 11:38 AM, Adam Back wrote:
Tin foil or not: maybe its time for 3072 RSA/DH and 384/512 ECC?
I'm inclined to agree with you, but you might be interested/horrified
in the 1024 bits is enough for anyone debate currently
On 22/09/13 03:07 AM, Patrick Pelletier wrote:
On 9/14/13 11:38 AM, Adam Back wrote:
Tin foil or not: maybe its time for 3072 RSA/DH and 384/512 ECC?
I'm inclined to agree with you, but you might be interested/horrified in
the 1024 bits is enough for anyone debate currently unfolding on the
Peter Fairbrother zenadsl6...@zen.co.uk writes:
If you just want a down-and-dirty 2048-bit FS solution which will work today,
why not just have the websites sign a new RSA-2048 sub-certificate every day?
Or every few hours? And delete the secret key, of course.
... and I guess that puts you
On 9/14/13 11:38 AM, Adam Back wrote:
Tin foil or not: maybe its time for 3072 RSA/DH and 384/512 ECC?
I'm inclined to agree with you, but you might be interested/horrified in
the 1024 bits is enough for anyone debate currently unfolding on the
TLS list:
On 18 September 2013 22:23, Lucky Green shamr...@cypherpunks.to wrote:
According to published reports that I saw, NSA/DoD pays $250M (per
year?) to backdoor cryptographic implementations. I have knowledge of
only one such effort. That effort involved DoD/NSA paying $10M to a
leading
On Wed, Sep 18, 2013 at 5:23 PM, Lucky Green shamr...@cypherpunks.towrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-09-14 08:53, Peter Fairbrother wrote:
I get that 1024 bits is about on the edge, about equivalent to 80
bits or a little less, and may be crackable either now
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-09-14 08:53, Peter Fairbrother wrote:
I get that 1024 bits is about on the edge, about equivalent to 80
bits or a little less, and may be crackable either now or sometime
soon.
Moti Young and others wrote a book back in the 90's (or
ianG writes:
On 14/09/13 18:53 PM, Peter Fairbrother wrote:
But, I wonder, where do these longer equivalent figures come from?
http://keylength.com/ (is a better repository to answer your question.)
I assume that web site only takes account of time, it does not base
its calculations to cost
Also see RFC 3766 from almost a decade ago; it has stood up fairly well.
--Paul Hoffman
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
On Sat, 14 Sep 2013 09:31:22 -0700 Paul Hoffman
paul.hoff...@vpnc.org wrote:
Also see RFC 3766 from almost a decade ago; it has stood up fairly
well.
For those not aware, the document, by Paul and Hilarie Orman,
discusses equivalent key strengths and practical brute force methods,
giving
On 14/09/13 17:14, Perry E. Metzger wrote:
On Sat, 14 Sep 2013 16:53:38 +0100 Peter Fairbrother
zenadsl6...@zen.co.uk wrote:
NIST also give the traditional recommendations, 80 - 1024 and 112
- 2048, plus 128 - 3072, 192 - 7680, 256 - 15360.
[...]
But, I wonder, where do these longer
On 14/09/13 18:53 PM, Peter Fairbrother wrote:
But, I wonder, where do these longer equivalent figures come from?
http://keylength.com/ (is a better repository to answer your question.)
iang
___
The cryptography mailing list
On Sat, Sep 14, 2013 at 12:56:02PM -0400, Perry E. Metzger wrote:
http://tools.ietf.org/html/rfc3766
| requirement | Symmetric | RSA or DH| DSA subgroup |
| for attack | key size | modulus size | size |
+-+---+--+--+
|100
50 matches
Mail list logo
