Re: [GNU Crypto] Documentation

[Raif S. Naffah]

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

hello Barry,

On Tue, 27 May 2003 12:07 am, baz wrote:
> Hi Raif,
>
> Yes, of course you're right about the possibility of a weak key being
> chosen at random, but I make the chances of this occuring
> approximately one in every 970,881,267,037,344,821. That's about a
> quidzillion to one. I would be happy with that for random generation.
>
> I suppose the real issue is with users of the library inventing their
> own keys, i.e. not random and possibly input by a user. Users have a
> habit of entering very simple things, but again, isn't that up to the
> application writer? I would be surprised if I used a library that
> contains a well known algorithm that allows any combination of bits
> for its key material and discovered it through exceptions because
> certain keys were considered weak.

the new exception i referred to earlier is a subclass of 
InvalidKeyException.  both our makeKey(...) method, and 
javax.crypto.Cipher.init(...) method (can) throw the 
InvalidKeyException checked exception.  in other words, the client 
code, which is try/catch-ing the InvalidKeyException would continue to 
function as before; i.e. there will be no (new) surprises :-)  new 
users however, as well as users of existing code who are willing (or 
capable) to treat weak keys differently, would add a catch for the new 
exception before falling through to InvalidKeyException.

the issue is effectively whether to include in the makeKey(...) method 
implementations checks for weak keys (and eventually other massaging 
functions required by the algorithm) and bailing out with this new 
exception if the key material is found to be in violation of certain 
pre-conditions; e.g. weak key.  or, do not apply those checks relying 
instead on the user alertness for ensuring the quality of the input key 
material.

i'd be also interested in hearing others' opinion on the subject.


> I think I'm coming from the point of view of a library
> user/application writer, as this is what I've done a lot of. I would
> expect the library documentation to tell me about the concept of weak
> keys, tell me about the methods I can call if I'm worried about this,
> but in the end let me use the library the way I want to.
>
> With regard to submitting code, I'm afraid I'm not well up on the
> theory behind cryptology, I've just used it a lot. The kind of thing
> I've done is write very easy to use wrapper classes around other
> APIs, e.g. to cover the kind of situation where a third party says:
>
> "Here is a sequence of ciphers defined by algorithm X, mode Y,
> padding scheme Z. Here is a key and an iv for each of these. When
> you're ready I will start sending you large chunks of data for you to
> decrypt."

well, i'm sure we can use more examples and how-tos in our documentation 
- --incl. Javadoc documentation.


> The other case is when I am requested to provide keys for algorithm
> X, etc. I may not really want to know too much about the details of
> algorithm X, so a key factory that makes random keys (strong and
> possibly parity adjusted) would suit me down to the ground.
>
> Maybe this would be a useful addition to the library and would give
> me something to do?

for sure.  an API and classes that are similar in functionality to 
javax.crypto.KeyGenerator (and JCE wrapper classes) would be nice to 
add to the library.  how does this sound?


> Best regards,
> barry
>
>
> ----- Original Message -----
> From: "Raif S. Naffah" <address@hidden>
> To: "baz" <address@hidden>
> Cc: "GNU Crypto" <address@hidden>
> Sent: Monday, May 26, 2003 12:00 PM
> Subject: Re: [GNU Crypto] Documentation
>
>
> 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+0zTN+e1AKnsTRiERA0JTAJ94wRiCE9jtbZjMWp7eke9GI3bu1gCfemNi
eYhLQHmeWS/OGJJznFuSB1k=
=68NM
-----END PGP SIGNATURE-----