Make instantiation of algorithms standard and based on the algorithm name and a pseudo-DSL

[stevenroose]

From @izaera on October 15, 2014 20:56

The idea is that a non-randomized algorithm state can be serialized/recovered with just its CipherParameters. I mean: if two algorithms with the same name receive the same CipherParameters, they must result in the same outputs for the same data.

Of course, this cannot be done if some algorithm is randomized, but in that case, the SecureRandom should be specified in the name so that it is made explicit. And also, it would still be considered the same algorithm, it's just that the randomization is different.

This change will allow to merge in pull request https://github.com/izaera/cipher/pull/82 that implements hashCode and equals for all CipherParameters.

If I cannot express SecureRandom as algorithm names and I cannot get rid of ParametersWithRandom, I won't merge it in because I don't like to have unstable semantics for these methods.

Copied from original issue: izaera/cipher#87

[stevenroose]

If parameters are serializable, please don't forget to implement hashCode and the == operator.

Btw, glad you're on cipher again :)

On Wed, Oct 15, 2014 at 10:56 PM, Ivan Zaera notifications@github.com wrote:

The idea is that a non-randomized algorithm state can be serialized/recovered with just its CipherParameters. I mean: if two algorithms with the same name receive the same CipherParameters, they must result in the same outputs for the same data.

Of course, this cannot be done if some algorithm is randomized, but in that case, the SecureRandom should be specified in the name so that it is made explicit. And also, it would still be considered the same algorithm, it's just that the randomization is different.

This change will allow to merge in pull request #82 https://github.com/izaera/cipher/pull/82 that implements hashCode and equals for all CipherParameters.

If I cannot express SecureRandom as algorithm names and I cannot get rid of ParametersWithRandom, I won't merge it in because I don't like to have unstable semantics for these methods.

— Reply to this email directly or view it on GitHub https://github.com/izaera/cipher/issues/87.

[stevenroose]

From @izaera on October 16, 2014 13:39

This bug is because of that PR ;-). It made me think about why ParametersWithRandom cannot implement equals and I think it's because there's something wrong with it. It's the only place where we are passing an "executable" object as a parameter. All other parameters are just data.

BTW: I've been always on cipher, it's just that I've been doing the entropy thing and it made me lose a lot of time. I'll upload the new spin off project soon.

[stevenroose]

From @izaera on October 17, 2014 21:31

I'll remove the init() method and the initialization parameters will be provided in the constructor with a simple syntax resembling a DSL.

For example, AES/CBC for encryption will be instantiated like this:

final aescbc = new BlockCipher("AES/CBC", {
  Param.ForEncryption: true,
  Param.Chain: [{
        Param.Key: [0x00,0x11,0x22,...,0xDD,0xEE,0xFF]
    }, {
        Param.IV: [0x00,0x11,0x22,...,0xDD,0xEE,0xFF]
  }]
});

The first param (ForEncryption) is passed to both AES and CBC. The ones inside the Chain are passed as the order in the algorithm name, i.e., the first one (Key) is for AES and the second (IV) for CBC.

Another benefit of this approach is that reset() is now easily implementable and semantically defined because it returns the state to the same point when the algorithm was created. Also, a new getter for the parameters will be provided that can be used in addition to the algorithmName to serialize the full definition of an algorithm.

[mathieujobin]

is the syntax in the comment above deprecated or still valid ?