Re: [GNU Crypto] P1363 integration

[Raif S. Naffah]

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

hello Marcel,

On Mon, 21 Apr 2003 11:26 am, Marcel Winandy wrote:
> 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.

agreed.  we do not have as yet support for, among other things, 
asymmetric key block ciphers, nor stream ciphers.  this however should 
and will be addressed as we integrate more contributions.


> [P1363 in general]
>
> First of all, IFES-RSA can be seen as a block cipher, too.

true; however, asymmetric key block ciphers are usually used to 
encrypt/decrypt one block that frames a datum (a symmetric key, or a 
hash of a message).  i'm not sure how P1363 views such algorithms 
and/or what API it suggests or implies to handle them.

so, although theoretically an asymmetric-key cipher can be used as a 
symmetric-key block cipher, in practice this is not usually the case.  
the point then becomes if we want to offer an API that does that; i.e. 
similar to IBlockCipher.

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

the same method is still usable since the current semantics of 
IBlockCipher.getCurrentBlockSize() throws an IllegalStateException if 
the instance is not initialised.  when initialised, how the instance is 
planned to be used will be specified; eg. encryption, or decryption.  
the getCurrentBlockSize() then returns the appropriate block size.

this reasoning is further justified, by the fact that asymmetric key 
block ciphers, unlike symmetric key block ciphers, do not have an 
'inherent' block size --as set by their designers.


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

what is the second parameter used for (with each encrypt- and/or 
decrypt-block operation)?

isn't it more a parameter of the setup of the algorithm that woul remain 
in force until the instance is reset?


> 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 think it's more appropriate to have two separate ones.  whether the 
asymmetric one is an extension of the other is subject to discussion.


> 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 personal preference is for a seprate API.  how does this API look 
like can be discussed on this list.


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

although instances of IBlockCipher are not immutables, that is still the 
case; i.e. once initialised they can not be changed until they are 
reset.


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

we considered that the implementations of IBlockCipher are basically the 
algorithms.  we tried to make then thread-safe but we probably can and 
should do a better job.

the class being the algorithm, allows the user to save resources if they 
want/need to.  all they need is to keep the instance and initialise it 
before they use it, and reset it afterwards.

i'm not convinced that this would make it less secure than immutable 
implementations.


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

basically for allowing users to save on object instantiation, 
finalisation operations.

again, users can not alter an IBlockCipher parameters, after it has been 
initialised and before it is reset.  i'll try adding a state diagram to 
the documentation to make it clear how the lifetime of an IBlockCipher 
object evolves.


> Bye,
>  Marcel


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

iD8DBQE+pRBx+e1AKnsTRiERA+YZAJ9zJ8HovVBFTJO1SHrEyO1KPWSAgwCgiscj
yJ6fw2L/gFafvVQ9HDf/RUo=
=oh8C
-----END PGP SIGNATURE-----