Re: [GNU Crypto] More keyrings, PBE.

[Raif S. Naffah]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

hello Casey,

On Wed, 8 Oct 2003 08:16 am, Casey Marshall wrote:
> >>>>> "Raif" == Raif S Naffah <address@hidden> writes:
> Raif> On Tue, 7 Oct 2003 07:30 am, Casey Marshall wrote:
> >> ...
> >> Other undefined packet identifiers should raise an error.
>
> Raif> i'd argue for treating them the same way unsupported optional
> Raif> packets are treated --similarly to the above, an implementation
> Raif> may emit a warning but not abort the process.
>
> I'm not so sure about that. Right now we have defined the bytes 0
> through 10 to have meaning as the prelude to a specific sequence of
> data; the presence of a byte 11-255 should be a signal that something
> is very wrong with the keyring, and since we don't know the form of
> this unknown packet, we don't know how many bytes to skip.
>
> UNLESS, we define that every packet (except property packets) all
> have this exact form:
>
>    uint8       Packet type.
>    eos         Properties (which defines things such as ciphers,
>                MACs, salts, etc.)
>    eos         Packet data.
>
> This does add some small costs in storage size and extra parsing
> steps, but I like the uniformity it brings to the format.

i concur.  my vote goes for uniformity :-)


> Raif> ...i'd rather see in the specs an unbounded way of
> Raif> specifying methods for such purposes; e.g. an encrypted packet
> Raif> would contain properties that fully define the parameters for
> Raif> encryption/decryption.  similarly for the authentication.
>
> >>  I would like to see the encoding identifiers (including such
> >> things as compression algorithms, encodings for keys,
> >> certificates) get moved into the properties field of the packet.
> >> My only concern with this is making sure the names are
> >> unambiguous.
>
> Raif> for mandatory packets it does not make a big difference,
> Raif> although using the same mechanism for all packets --i.e. based
> Raif> on values of properties -- is IMO a plus.  if we put the
> Raif> emphasis on the property names rather than on IDs, we have more
> Raif> flexibility --i.e. we only have to update the list of
> properties Raif> when new technologies arise; yet with the same set
> of properties Raif> we allow implementations to support a larger
> combinations of Raif> algorithms.
>
> Another possibility is to define one more algorithm ID for every
> packet that deals with an encoding, e.g.
>
>    #define  GKR_CIPHER_PRIVATE 255
>
> In which case the actual name of the cipher and mode will be included
> in the packet's properties.

and keep the

#define GKR_CIPHER_AES_128_OFB 0
#define GKR_CIPHER_AES_128_CBC 1

types as possible instances of GKR_TYPE_ENCRYPTED?

or remove the two cipher/mode/padding combo IDs and replace them with 
properties?

if it's the latter do we really need an additional packet ID?


cheers;
rsn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE/g9YE+e1AKnsTRiERA/7YAJsEHd/kh6ZYZOK7lmcx7zm5Gj39JwCeNVGv
ccszNpXKL0+P9tzrcsK2yF4=
=Vrd0
-----END PGP SIGNATURE-----