On Mon, Sep 30, 2013 at 11:49:49AM +0300, ianG wrote:
On 30/09/13 11:02 AM, Adam Back wrote:
no ASN.1, and no X.509 [...], encrypt and then MAC only, no non-forward
secret ciphersuites, no baked in key length limits [...] support
soft-hosting [...] Add TOFO for self-signed keys.
Personally,
If we're going to do that I vote no ASN.1, and no X.509. Just BNF format
like the base SSL protocol; encrypt and then MAC only, no non-forward secret
ciphersuites, no baked in key length limits. I think I'd also vote for a
lot less modes and ciphers. And probably non-NIST curves while we're at
I am not sure if everyone is aware that there is also an unmoderated crypto
list, because I see old familiar names posting on the moderated crypto list
that I do not see posting on the unmoderated list. The unmoderated list has
been running continuously (new posts in every day with no gaps)
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.
On 29 Sep 2013, at 08:51, ianG i...@iang.org wrote:
On 28/09/13 20:07 PM, Stephen Farrell wrote:
b) is TLS1.3 (hopefully) and maybe some extensions for earlier
versions of TLS as well
SSL/TLS is a history of fiddling around at the edges. If there is to be any
hope, start
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 2013-09-30 14:34, Viktor Dukhovni wrote:
On Mon, Sep 30, 2013 at 05:12:06AM +0200, Christoph Anton Mitterer wrote:
Not sure whether this has been pointed out / discussed here already (but
I guess Perry will reject my mail in case it has):
On 29/09/13 16:01 PM, Jerry Leichter wrote:
...e.g., according to Wikipedia, BATON is a block cipher with a key length of
320 bits (160 of them checksum bits - I'd guess that this is an overt way for
NSA to control who can use stolen equipment, as it will presumably refuse to
operate at all
On 30/09/13 11:02 AM, Adam Back wrote:
If we're going to do that I vote no ASN.1, and no X.509. Just BNF format
like the base SSL protocol; encrypt and then MAC only, no non-forward
secret
ciphersuites, no baked in key length limits. I think I'd also vote for a
lot less modes and ciphers. And
On 30 September 2013 10:47, Adam Back a...@cypherspace.org wrote:
I think lack of soft-hosting support in TLS was a mistake - its another
reason not to turn on SSL (IPv4 addresses are scarce and can only host one
SSL domain per IP#, that means it costs more, or a small hosting company
can
On 29/09/13 16:13 PM, Jerry Leichter wrote:
On Sep 26, 2013, at 7:54 PM, Phillip Hallam-Baker wrote:
...[W]ho on earth thought DER encoding was necessary or anything other than
incredible stupidity?...
It's standard. :-)
We've been through two rounds of standard data interchange
On Mon, Sep 30, 2013 at 05:45:52PM +1000, James A. Donald wrote:
On 2013-09-30 14:34, Viktor Dukhovni wrote:
On Mon, Sep 30, 2013 at 05:12:06AM +0200, Christoph Anton Mitterer wrote:
Not sure whether this has been pointed out / discussed here already (but
I guess Perry will reject my mail
Bumber sticker:
Remember, the NSA is Backing You Up
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
On 9/30/13 at 1:16 AM, i...@iang.org (ianG) wrote:
Any comments from the wider audience?
I talked with a park ranger who had used a high-precision GPS
system which decoded the selective availability encrypted
signal. Access to the device was very tightly controlled and it
had a
On Mon, 30 Sep 2013 11:47:37 +0200
Adam Back a...@cypherspace.org wrote:
I think lack of soft-hosting support in TLS was a mistake - its
another reason not to turn on SSL (IPv4 addresses are scarce and can
only host one SSL domain per IP#, that means it costs more, or a
small hosting company
On Mon, 2013-09-30 at 14:44 +, Viktor Dukhovni wrote:
If SHA-3 is going to be used, it needs to offer some advantages
over SHA-2. Good performance and built-in support for tree hashing
(ZFS, ...) are acceptable reasons to make the trade-off explained
on slides 34, 35 and 36 of:
Well I
GOST was specified with S boxes that could be different for different
applications, and you could choose s boxes to make GOST quite weak. So that's
one example.
--John
___
The cryptography mailing list
cryptography@metzdowd.com
On Sep 30, 2013, at 4:16 AM, ianG i...@iang.org wrote:
I'm not really understanding the need for checksums on keys. I can sort of
see the battlefield requirement that comms equipment that is stolen can't
then be utilized in either a direct sense (listening in) or re-sold to some
other
Why can't we just designate some big player to do it, and follow suit? Why
argue in committee?
Well, there are Protobufs, and there is Thrift, and there is
MessagePack, and there is Avro...
http://www.igvita.com/2011/08/01/protocol-buffers-avro-thrift-messagepack/
..m
Bill said he wanted a piece of paper that could help verify his bank's
certificate. I claimed he's in the extreme minority who would do that and he
asked for proof.
I can only, vaguely, recall that one of the East Coast big banks (or perhaps
the only one that is left) at one point had a
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
On 2013-10-01 00:44, Viktor Dukhovni wrote:
Should one also accuse ESTREAM of maliciously weakening SALSA? Or
might one admit the possibility that winning designs in contests
are at times quite conservative and that one can reasonably
standardize less conservative parameters that are more
On 2013-09-30 18:02, Adam Back wrote:
If we're going to do that I vote no ASN.1, and no X.509. Just BNF format
like the base SSL protocol;
Granted that ASN.1 is incomprehensible and horrid, but, since there is
an ASN.1 compiler that generates C code we should not need to comprehend it.
Hi,
What I personally think would be necessary for TLS2:
* At least one quantum-computing resistant algorithm which must be useable
either as replacement for DH+RSA+EC, or preferrably as additional
strength(double encryption) for the transition period.
* Zero-Knowledge password authentication
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 Mon, Sep 30, 2013 at 2:27 PM, James A. Donald jam...@echeque.com wrote:
Granted that ASN.1 is incomprehensible and horrid, but, since there is an
ASN.1 compiler that generates C code we should not need to comprehend it.
What about tools that want to comprehend it using something other than
On Mon, Sep 30, 2013 at 1:02 AM, Adam Back a...@cypherspace.org wrote:
If we're going to do that I vote no ASN.1, and no X.509. Just BNF format
like the base SSL protocol; encrypt and then MAC only, no non-forward
secret
ciphersuites, no baked in key length limits. I think I'd also vote for
On Tue, Oct 01, 2013 at 07:21:03AM +1000, James A. Donald wrote:
On 2013-10-01 00:44, Viktor Dukhovni wrote:
Should one also accuse ESTREAM of maliciously weakening SALSA? Or
might one admit the possibility that winning designs in contests
are at times quite conservative and that one can
On 9/30/13 11:07 PM, Jerry Leichter wrote:
On Sep 30, 2013, at 4:16 AM, ianG i...@iang.org wrote:
But it still doesn't quite work. It seems antithetical to NSA's obsession
with security at Suite A levels, if they are worried about the gear being
snatched, they shouldn't have secret
If you want to understand what's going on wrt SHA3, you might want to look at
the nist website, where we have all the slide presentations we have been giving
over the last six months detailing our plans. There is a lively discussion
going on at the hash forum on the topic.
This doesn't make
On 9/30/13 at 2:07 PM, leich...@lrw.com (Jerry Leichter) wrote:
People used to wonder why NSA asked that DES keys be
checksummed - the original IBM Lucifer algorithm used a full
64-bit key, while DES required parity bits on each byte. On
the one hand, this decreased the key size from 64 to
On Mon, Sep 30, 2013 at 2:21 PM, James A. Donald jam...@echeque.com wrote:
On 2013-10-01 00:44, Viktor Dukhovni wrote:
Should one also accuse ESTREAM of maliciously weakening SALSA? Or
might one admit the possibility that winning designs in contests
are at times quite conservative and that
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 2013-10-01 04:22, Salz, Rich wrote:
designate some big player to do it, and follow suit?
Okay that data encoding scheme from Google protobufs or Facebook thrift. Done.
We have a complie to generate C code from ASN.1 code
Google has a compiler to generate C code from protobufs source
The
35 matches
Mail list logo
