On 2/10/13 00:43 AM, James A. Donald wrote:
On 2013-10-01 14:36, Bill Stewart wrote:
It's the data representations that map them into binary strings that
are a
wretched hive of scum and villainy, particularly because you can't
depend on a
bit string being able to map back into any well-defined
On 2013-10-02 13:18, Tony Arcieri wrote:
LANGSEC calls this: full recognition before processing
http://www.cs.dartmouth.edu/~sergey/langsec/occupy/
http://www.cs.dartmouth.edu/%7Esergey/langsec/occupy/
I disagree slightly with langsec.
At compile time you want an extremely powerful language
On 1/10/13 23:13 PM, Peter Fairbrother wrote:
...
Sounds like you want CurveCP?
http://curvecp.org/
Yes, EXACTLY that. Proposals like CurveCP.
I have said this first part before:
Dan Boneh was talking at this years RSA cryptographers track about
putting some sort of
On 1/10/13 02:01 AM, Tony Arcieri wrote:
On Mon, Sep 30, 2013 at 1:02 AM, Adam Back a...@cypherspace.org
mailto: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
On 01/10/13 08:54, ianG wrote:
On 1/10/13 02:01 AM, Tony Arcieri wrote:
On Mon, Sep 30, 2013 at 1:02 AM, Adam Back a...@cypherspace.org
mailto: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
At 02:27 PM 9/30/2013, James A. Donald wrote:
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
On 2013-10-01 14:36, Bill Stewart wrote:
It's the data representations that map them into binary strings that
are a
wretched hive of scum and villainy, particularly because you can't
depend on a
bit string being able to map back into any well-defined ASN.1 object
or even any limited size of
On 2013-10-01 14:36, Bill Stewart wrote:
It's the data representations that map them into binary strings that
are a
wretched hive of scum and villainy, particularly because you can't
depend on a
bit string being able to map back into any well-defined ASN.1 object
or even any limited size of
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
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
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 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 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
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
17 matches
Mail list logo
