[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Canonical form for signing S-expressions

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Ben" == Ben Laurie <ben@gonzo.ben.algroup.co.uk> writes:
    >> Example: The S-expression (a b (cd e fgh)) has canonical form
    >> for signing (#1:a#1:b(#2:cd#1:e#3:fgh))

    Ben> Seems to me that the # is redundant, and should, therefore,
    Ben> be left out.

  Giving:
	(1:a1:b(2:cd1:e3:fgh))

  If we want to be as nice to the parser as possible, then let's
indicate the number of items in each S-expression, and/or its size (or
both).
  The only difference between the format that I proposed several weeks
ago, and the format above is that my format would look more like:
	1:a(1:b2:cd(1:e3:fgh))

  with the knowledge of what is in the () available only to
applications that know what the 'a' tag is. 
  The other major difference is that my tags were fixed length, with
the size set to 4. The length field was also fixed, while this one is
variable size.

  I frankly don't care.
  One thing that I can see about this format is that I can see doing 
a lot of things "inline" ... without additional storage. 
	(1:a1:b(2:cd1:e3:fgh))
  becomes:
	(XXaAAb(YYcdXXeZZfgh))
	XX = binary short representation for 1
	YY = binary short representation for 2
	ZZ = binary short representation for 3
	AA = 2^16 || XX

  then, once you have the tree decoded, you simply have a packed array
of elements like:
	struct atom { short atom:1; short len:15; char displayname[]; };

  I note that with a hex external representation, there is always
enough space to store a binary, plus one bit for atom/sublist.
  One can even accumulate the binary representation inplace on byte
addressable big endian machines.
  (systems with alignment issues loose)

   :!mcr!:            |  Network security consulting and 
   Michael Richardson |      contract programming
 WWW: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQB1AwUBM1J7baZpLyXYhL+BAQHRhQL+PaPOjTWkao2tMlkJT4HUcVg5DjkOgIzO
Q4Pc5Zhut7IsxNLpnczVjviu2g5lNjPVTDgUs3y2xdSyMK2D6nZYYQlpns3dRS0L
s2DutG9haYZSaJUlm4gm27tWuG1aKJO5
=ymQ0
-----END PGP SIGNATURE-----
Follow-Ups: References: