[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Canonical form for signing S-expressions
Yep. I hadn't thought about using multiple delimiters, I just wanted
to point out the flaw. I'm glad someone else came up with a working
alternative.
However, I'm wondering if this is too much overhead. Are we adding
more bytes in the encoding process than what we're actually encoding?
In the long run it probably isn't much overhead, but these examples
sure look like it is. I've seen protocols that convert numbers to hex
form for transport "to make them readable by a human." Unfortunately
this example protocol isn't very extensibile since it limits the size
of data that can be input. (This is MIT's Zephyr Protocol, and the
conversion is for Kerberos Authenticator information -- it doesn't
work with Kerberos v5 because the krb5 authenticators are too big).
Mostly, I just want the encoding to be as compact as possible. I'd
prefer binary encoding (as opposed to decimal or hex), but that opens
up other problems which I doub this group is interested in tackling.
-derek
Alan Barrett <apb@iafrica.com> writes:
>
> On 14 Apr 1997, Derek Atkins wrote:
> > The only problem with this is that you now have an ambiguous recursion
> > problem. How do you know when:
> > 30:(1:a,1:b,16:(2:cd,1:e,3:fgh),),
> > means
> > '((1:a,1:b,16:(2:cd,1:e,3:fgh),))
> > or
> > (a b (cd e fgh)
>
> Oops! Thanks. (I was also missing the "," in "3:fgh,".)
>
> As Ron Rivest has already pointed out, using different delimiters
> can fix that.
>
> --apb (Alan Barrett)
>
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH
warlord@MIT.EDU PGP key available
Follow-Ups:
References: