gnu-crypto-discuss
[Top][All Lists]
Advanced

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

Re: [GNU Crypto] Documentation


From: Raif S. Naffah
Subject: Re: [GNU Crypto] Documentation
Date: Mon, 26 May 2003 19:39:28 +1000
User-agent: KMail/1.5.1

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]