[147321] in cryptography@c2.net mail archive
Re: [Cryptography] RSA recommends against use of its own products.
daemon@ATHENA.MIT.EDU (James A. Donald)
Sun Sep 29 02:11:51 2013
X-Original-To: cryptography@metzdowd.com
Date: Sun, 29 Sep 2013 15:29:26 +1000
From: "James A. Donald" <jamesd@echeque.com>
To: cryptography@metzdowd.com
In-Reply-To: <CAMm+LwgOUOJMzErKN550gex0_mSAenDw7CXfm=xek5azB3mioQ@mail.gmail.com>
Reply-To: jamesd@echeque.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
This is a multi-part message in MIME format.
--===============6548593664056493909==
Content-Type: multipart/alternative;
boundary="------------030708050001040707020700"
This is a multi-part message in MIME format.
--------------030708050001040707020700
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 2013-09-27 09:54, Phillip Hallam-Baker wrote:
>
> Quite, who on earth thought DER encoding was necessary or anything
> other than incredible stupidity?
>
> I have yet to see an example of code in the wild that takes a binary
> data structure, strips it apart and then attempts to reassemble it to
> pass to another program to perform a signature check. Yet every time
> we go through a signature format development exercise the folk who
> demand canonicalization always seem to win.
>
> DER is particularly evil as it requires either the data structures to
> be assembled in the reverse order or a very complex tracking of the
> sizes of the data objects or horribly inefficient code. But XML
> signature just ended up broken.
We have a compiler that generates C code from ASN.1 code. Does it not
generate code behind the scenes that does all this ugly stuff for us
without us having to look at the code?
I have not actually used the compiler, and I have discovered that hand
generating code to handle ASN.1 data structures is a very bad idea, but
I am told that if I use the compiler, all will be rainbows and unicorns.
You go first.
--------------030708050001040707020700
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2013-09-27 09:54, Phillip
Hallam-Baker wrote:<br>
</div>
<blockquote
cite="mid:CAMm+LwgOUOJMzErKN550gex0_mSAenDw7CXfm=xek5azB3mioQ@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><br>
<div>Quite, who on earth thought DER encoding was necessary
or anything other than incredible stupidity?</div>
<div><br>
</div>
<div>I have yet to see an example of code in the wild that
takes a binary data structure, strips it apart and then
attempts to reassemble it to pass to another program to
perform a signature check. Yet every time we go through a
signature format development exercise the folk who demand
canonicalization always seem to win.</div>
<div><br>
</div>
<div>DER is particularly evil as it requires either the data
structures to be assembled in the reverse order or a very
complex tracking of the sizes of the data objects or
horribly inefficient code. But XML signature just ended up
broken.</div>
</div>
</div>
</div>
</blockquote>
<br>
We have a compiler that generates C code from ASN.1 code. Does it
not generate code behind the scenes that does all this ugly stuff
for us without us having to look at the code?<br>
<br>
I have not actually used the compiler, and I have discovered that
hand generating code to handle ASN.1 data structures is a very bad
idea, but I am told that if I use the compiler, all will be rainbows
and unicorns.<br>
<br>
You go first.<br>
</body>
</html>
--------------030708050001040707020700--
--===============6548593664056493909==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============6548593664056493909==--
