Re: [GNU Crypto] What to do with bugs?

[Raif S. Naffah]

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

hello Mikael,

On Sun, 21 Sep 2003 06:01 am, Mikael Hakman wrote:
> On Saturday, 20 September, 2003 18.16, Raif S. Naffah wrote
> > On Sun, 21 Sep 2003 12:08 am, Mikael Hakman wrote:
> >> ...
> >> What do you do if you think you discovered some bugs...
> >
> > the minimum is to report the bug and describe the environment to
> > help reproduce it.
> >
> > the next best thing is to include in the report a test-case that
> > fails the expected outcome, and if possible --the optimal way ;-)--
> > a patch. this way the test-case can be used to show the before- and
> > after-patch effects.
>
> Ok, let's try with the minimum - maybe these are known bugs.
>
> 1. gnu.crypto.jce.cipher.CipherAdapter
>
> engineUpdate(byte[] in, int inOff, int inLen, byte[] out, int outOff)
>
> It does not update partBlock/partLen correctly when inLen<blockSize.
> In particular when inLen=1 as is the case when using JCE
> CipherStreams only the very last block is processed. There are bugs
> in several places in this function.
>
> 2. gnu.crypto.jce.cipher.CipherAdapter
>
> engineDoFinal(byte[] input, int off, int len)
>
> Errors when decrypting when len<(len of actual padding) - some or all
> pad bytes has already been processed in such case, in particular when
> parameter len=0. This happens when application calls e.g. doFinal()
> after is has processed the whole input.

thanks for these two reports.  i'll look into them as soon as i checkin 
the current classes i'm working on.

in the absence of test-cases it is hard (for me at least) to say now if 
they are, or not, bugs.  i'll try to write some test cases to reproduce 
the scenarios you describe.  either way, i'll keep you informed of the 
outcome.


> 3. This is not related to the code but to padding spec - what happens
> when an encrypted file has a blockSize-integral length and its very
> last bytes look like padding bytes would, had the file been somewhat
> shorter?

both parties must know whether they are working with a padding, or 
non-padding, cipher.  with padding ciphers, padding algorithms are 
clear on how to treat the last block.  most add an additional block if 
the non-padded part is a multiple of the cipher's block size.

another thing to keep in mind is that both parties know how long the 
ciphertext is --how many bytes were produced by the encryptor, and how 
many are to be consumed by the decryptor.  that fact allows the 
decryptor to invoke a doFinal() rather than an update().  obviously 
only the former would involve a padding algorithm if the cipher is a 
padding one.


> 4. My environment
>
> I'm using source dist of gnu-crypto ver 1.1.0 in Eclipse IDE. There
> are few problems with dist w.r.t Eclipse but this is not critical
> right now.
>
> 5. What are gpg commands to get the envelope you are providing? Is
> there any plugin for OE that can automatically pack-in/pack-out
> emails?

i'm not sure i understand your question.  if you're referring to Casey's 
proposed GNU Keyring file format, this is still a proposal to be 
implemented; i.e. there's still no (publicly available) tool, gpg or 
otherwise, that can read/write such packets.

as for OE --which i presume is an abbreviation for Outlook Express-- 
you're better off, directing your question to the GPG mailing list 
<address@hidden>.


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

iD8DBQE/bQZk+e1AKnsTRiERA+ZgAKCh+6ILgdNGny8VRZRmxryjbH2MQACg9SC5
wTxBCX6zbF/5VER3KGmQCxk=
=RMrh
-----END PGP SIGNATURE-----