Re: [GNU Crypto] Documentation

[Raif S. Naffah]

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

hello Barry,

On Mon, 26 May 2003 07:59 pm, baz wrote:
> 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.

true.  but should we allow it?  wouldnt you feel safer if/when the 
implementation throws an exception if the key is weak?

my rationale is not to allow this to happen.


> 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!

yes small but not inexistant.  the question is what do we do if it 
happens?


> 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.

to my knowledge, DES is the only one, among those implemented in the 
library that has such keys.


> 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?

although not necessary, that would be a nice addition.

as Casey pointed out earlier, in the case of DES: (a) there are static 
methods to test and set/adjust the parity, and (b) the appropriate 
method(s) can be invoked in makeKey().  this way, GNU Crypto 
implementation is (or would become) resiliant wrt. the quality of the 
input key material, wherever it comes from.


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

nice to hear :-)  thanks for taking the time to try it and make 
suggestions for improvement.  the next step of course is contributing 
code?!


> 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
>
> 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

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

iD8DBQE+0fO6+e1AKnsTRiERA6RIAJ45/HLXGX6Uw365TttuYHn1IOjocgCfcYNX
z40isPslUnYjXvTlRQJhxwY=
=0MYH
-----END PGP SIGNATURE-----