Re: [GNU Crypto] Documentation

[baz]

Hi,

I'm not convinced of the usefulness of a WeakKeyException for two reasons:

1) It is not an invalid key. The cipher still works.
2) I counted only 19 weak and semi-weak (DES) keys. If a user of the library
is randomly generating 8 byte keys then the chances of generating a weak key
are pretty small!

I don't know about all the other ciphers, but I suspect that if they have
weak keys then they'd be just as unlikely to be found at random.

What might be more of an issue is the subject of parity. This is why I
mentioned key generation before. For example, if a random sequence of bytes
is used as a key then it can be adjusted to the correct parity in a number
of ways. If a key generated by random is passed between individuals then
their respective software might adjust it differently, so it's all the more
important to generate a completely correct key to start with.

I can envisage something along the lines of a
SymmetricBlockCipherKeyFactoryThingy with a method like:

byte[] generate( String algorithm );

This could delegate to the concrete cipher implementation classes. Maybe?

I must say, I am most impressed with the library so far!

barry

----- Original Message -----
From: "Raif S. Naffah" <address@hidden>
To: "Casey Marshall" <address@hidden>
Cc: "GNU Crypto" <address@hidden>
Sent: Monday, May 26, 2003 10:39 AM
Subject: Re: [GNU Crypto] Documentation


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

On Mon, 26 May 2003 09:37 am, Casey Marshall wrote:
> On Mon, May 26, 2003 at 06:59:57AM +1000, Raif S. Naffah wrote:
> > On Mon, 26 May 2003 05:23 am, baz wrote:
> >
> > [...]
> >
> > > How about renaming 'Stage.getInstace'?  :-)
> >
> >                                    ^^
> > to what?  once the Cacscade and Assembly are documented, it should
> > become easy(ier) to have a clear mental image of what the building
> > blocks are --and the names then would make more sense.  (this is
> > the theory at least :-)
>
> To 'getInstance'.

yes of course (blush).  i'll fix this asap.


> > > Lastly, there is nothing in the library for generating keys.
> > > Correct me if I'm wrong but I thought that not all encryption
> > > schemes use an entirely random sequence of bits for their keys.
> > > Don't some require a certain parity?
> >
> > true.  certain algorithms exhibit certain "weakness" with some
> > specific key values (i.e. weak and semi-weak keys); e.g. DES.
> > currently, the library does not ensure/enforce such constraints.
> > this will be addressed in future versions.
>
> DES does contain static methods for testing if a given key is weak,
> as well as methods for testing/altering the parity bits. It's trivial
> to add a test for them in the initialization.

i forgot about those static methods.  adding the test that would be nice
- --see later.


> The parity bits are now just an anachronism; if you give a non-parity
> adjusted key to the makeKey method, it will produce the same result
> as a parity adjusted key (erm, probably).

i'll take your word for it :-)


> So, isn't it the case that you can feed any arbitrary key bytes (of
> the proper length) into any of the ciphers, and be guaranteed that
> they will work?

yes  --by "will work" i take it that checks for [semi-]weak keys are
done in makeKey() mehod (also called by the init() method).  we can
envisage a new exception (a subclass of InvalidKeyException, say
WeakKeyException) that gets thrown if the cipher is initialised with
weak key material.  this way existing code will continue to work, and
the implementation will become more robust.

does this make sense?


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

iD8DBQE+0eDQ+e1AKnsTRiERAy04AJsHKYZRhAEcJnJXhs6O78GtTzqNBQCgnuxP
E/jB7l/wYORXjO9qDlP1bvc=
=MCUZ
-----END PGP SIGNATURE-----



_______________________________________________
gnu-crypto-discuss mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/gnu-crypto-discuss