[GNU Crypto] P1363 integration

[Marcel Winandy]

Hello!

I have examined the ciphers package of GNU Crypto and compared it to my 
implementation of IEEE P1363. If you want to integrate asymmetric ciphers
(like IFES-RSA from P1363) into the gnu.crypto.ciphers package there are some
general problems.

[P1363 in general]

First of all, IFES-RSA can be seen as a block cipher, too. However, the
gnu.crypto.ciphers.IBlockCipher interface wouldn't be compatible to P1363
ciphers. IBlockCiphers defines only one method to get the block size which
will be transformed by the cipher, namely IBlockCipher.currentBlockSize(). In
P1363 we will need two different block sizes - one for encryption and one for
decryption. Furthermore the block sizes depend on the key pair used for
encryption/decryption.

Secondly and similarly, the encryption and decryption operations of P1363
encryption schemes need two input parameters, namely the message and some
encoding parameters, both of them are byte arrays. The corresponding methods
in IBlockCipher, namely encryptBlock() and decryptBlock(), have only one
input byte array.

So, I think a general design decision must be made. Shall there be one
general interface for both symmetric and asymmetric ciphers or shall there be
two different interfaces?

I would suggest to have one common interface. But this means we have to change
IBlockCiphers and, of course, all implementing classes that exists yet. My
suggestion would be something like that (offsets not dealt with):
  IBlockCipher.encryptBlock(byte[] plaintext, byte[] encodingParams, 
                                         byte[] ciphertext);
  IBlockCipher.decryptBlock(byte[] ciphertext, byte[] encodingParams, 
                                         byte[] plaintext);
  int IBlockCipher.currentEncryptionBlockSize();
  int IBlockCipher.currentDecryptionBlockSize();

Maybe the encryptBlock() and decryptBlock() methods can be overloaded, so we
can keep the 'old' interface and reduce changing code of existing classes. The
'old' encryptBlock() and decryptBlock() methods would be a special case -
ignoring the encoding parameters.


[My P1363 implementation and security considerations]

There is another issue about P1363 and GNU Crypto according to my own 
implementation of P1363. Security was the most important design goal of my 
group. Especially, we considered attacks that try to tamper our application 
(namely trojan horse programs) from outside _and_ from the inside
of the application (possibly exchanged components). So we made important 
objects "immutable": Once they are created they cannot be modified or altered 
by calling their methods or changing their attributes.

The main consequence is that objects implementing encryption schemes will get 
their encryption parameters (random number generator, primality test 
algorithm and the key) as arguments in the constructor. They cannot be 
changed during the lifetime of one object. If you want to encrypt/decrypt 
with different parameters, e.g. with another key, you'll have to create 
another object with those parameters.

However, GNU Crypto uses special init() and reset() methods to change 
cryptographic parameters during an object's lifetime. My question: why did 
you do this? Is there a special reason to allow altering an encryption object 
at runtime?

Bye,
 Marcel
-- 
Marcel Winandy
EMail: address@hidden
http://www-student.informatik.uni-bonn.de/~winandy/