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

[Raif S. Naffah]

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

hello Mikael,

On Mon, 22 Sep 2003 12:53 am, Mikael Hakman wrote:
> 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.

thanks.


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

no, you only need the extra block if the non-padded part is a multiple 
of the block size.  for example:

* using an 8-byte block cipher, i want to encrypt the following sequence 
of 6 ASCII codepoints: MIKAEL.  because the cipher blocksize is 8 i 
need to add 2 padding bytes; with PKCS7 these will be both 0x02, and 
the total output is the result of encrypting the sequence:

   M I K A E L 0x0202

* on the other side,  my correspondant would decrypt the sequence, and 
if everything goes without error, he should get the same as above.  
knowing that i used PKCS7 padding, he would then look at the last 
octet, and knows to discard 2 bytes.

* on the other hand, if i want to encrypt the sequence (MIKAEL), which 
is already 8 bytes, i need to add an extra 8-byte block consisting, 
again with PKCS7, of eight 0x08 octets.  the total input sequence to 
the encryption is then:

   ( M I K A E L )   0x0808080808080808

* my correspondant, after decryption should get the same, and would 
discard the rightmost 8 bytes.

in both cases, my correspondant got the right plaintext, and i only used 
an extra block when the input was a multiple of the cipher's blocksize 
before padding.


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

correct.


>... Also such an implementation has to add/remove
> that extra padding block from above if padding is used.

more accurately, the implementation has to know how to manage padding, 
be it (a) discarding some bytes from the temporary block (case 1 in the 
example above), or (b) a full block (case 2).


> 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 havent looked at the JCE documentation for a very long time, but i 
dont remember any special case wrt. cipher streams.  as explained 
above, and you already hinted to the right way of dealing with padding, 
all the implementation has to do is keep the equivalent of a block in 
transit and only return the final result of what's inside that block 
when the doFinal() is invoked.  calling update() even repeatedly should 
not alter the fact that the implementation is, always, keeping 1 block 
in temporary storage.  only when the doFinal() is called --by the 
flush() or close()-- does the implementation process that temp buffer.


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

this is indeed a digital signature for the message, and it's a personal 
choice not a requirement for posting to the list.  you may find these 
links of use to you:

http://www.winpt.org/gpgoe.html
http://www3.gdata.de/gpg/index.html
http://winpt.sourceforge.net/en/

more information on privacy, tools, frontends, and documentation is 
always available on the GNU Privacy Guard project home page:

http://www.gnupg.org/


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

iD8DBQE/ben6+e1AKnsTRiERAwswAKCvwInbgLYPp9lbmBajCnrdZkNZ2wCgqJfd
3BzMq9l79YAmkSWwUlnOMkg=
=LnzT
-----END PGP SIGNATURE-----