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

[Mikael Hakman]

On Sunday, 21 September, 2003 04.01,Raif S. Naffah wrote:
> 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

Please find a simple test case in the attached test-cases.jar file.
You can run the test case directly out of jar by:

java -classpath .\test-cases.jar EngineUpdateCase1 <file-in> <file-out>

where <file-in> is file to be encrypted and <file-out> is resulting
encrypted file.

I'll send you a test case for case 2 soon.

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

Please forgive me my ignorance, but if you do not add an extra block when
non-padded part is not a multiple the cipher's block size and you find e.g.
five 5 (PKCS7) at the end of message when decrypting - what do you know
then? Are these 5:s padding or are these 5:s simply a result of encrypting
of
the extra block? If I understand this correctly then the general policy
would
be to always add an extra block to message being encrypted and then use
that block for padding purposes only when decrypting?

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

If both parties agree to always add an extra block for padding purposes then
this should work.

However, when using JCE CipherStreams you don't call doFinal() at all.
You simply flush() and close() the output stream and the end of input
stream. This means that implementations of CipherStreams must be
intelligent enough to double buffer at least one full block (the previous
block so to speak) so the padding may be recovered when close() call comes
in. Also such an implementation has to add/remove that extra padding block
from above if padding is used.

What does the JCE spec say about update(), doFinal() and CiperStreams
in connection with padding? Does it require to call doFinal() with the
last block and not update() when using padding? Does it exclude using
CiperStreams when using padding?

> 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

I have noticed that most messages to this list start with a text like:

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

and end with a text like this:

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

I'm assuming that this is a signature envelope. The question was
how to produce such an envelope so that you can verify/read it
without problems. I'm simply trying to adjust to this list's habits.

Mikael

test-cases.jar
Description: Binary data