Provide means of serializing keys

[snoyberg]

In trying to upgrade clientsession to work with cryptocipher 0.4.0, I ran up against the fact that there is no Serialize instance available, and seemingly no way to make one. What I'm really trying to do is just recreate the previous AES256 datatype. You can see my initial work here:

https://github.com/yesodweb/clientsession/commit/21038d04b31bb3e1573c33bcd29558bf628b401a

Do you have any recommendations for how to proceed?

Pinging @meteficha as well in case he has some ideas.

[meteficha]

It's easy to add serialization support for the keys. Actually, using GeneralizedNewtypeDeriving I guess we may just deriving (Serialize).

However, I don't really like not having support for crypto-api anymore on crypto-cipher, it seems as a step backwards. I understand that the performance may be worse, but this should be a reason to document the performance characteristics of each interface, not to remove one of them.

[meteficha]

@snoyberg, on the clientsession side we may directly use cipher-aes's interface as well instead of using it via crypto-api. This won't solve the serialization problem but will avoid needing to define the relevant instances ourselves and possibly be faster. At a glance, it seems that we'll just need to use encryptCTR.

[vincenthz]

quick reply during lunch break, sorry can't elaborate much:

• the serialization instance could be defined using this https://github.com/vincenthz/hs-cipher-aes/issues/3
• don't serialize the whole (cipher-aes) Key, this is not equivalent to what the the crypto-api instance is doing, which is extracting the key given by the user to initKey.
• extracting the user key from Key is more portable, however you could store the Key directly and save the whole thing, which will avoid a costy initKey when unserializing the key. it will break the actual database format though.
• Removing the instance wasn't planned per-se, it's just a side effect of using the much better cipher-aes.
• Block cipher crypto-api instance are terribly slow. there's no way to improve CBC/CTR/etc mode until it's fundamentally fixed. following is using cipher-aes using crypto-api interface or the native interface.
  • encrypting 32 bytes with aes256 : 1070ns -> 195ns.
  • encrypting 1024 bytes with aes256: 28 us -> 2.17 us.
  • encrypting 32 bytes with aes128 (aesni powered): 547 ns -> 162ns
  • encrypting 1024 bytes with aes128 (aesni powered): 28 us -> 2.16us
• you better not use Serialize to serialize something that is a newtyped bytestring. it's 340ns compared to 11ns on my laptop. Same is true for a datatype with 2 bytestring fields (57ns compared to 520ns)
• yes encryptCTR is the way to go.

edit: just corrected a typo "2.16ns" is actually "2.16us" in aes128 1024 bytes.

[TomMD]

WRT crypto-api. I will be adding the modes as overridable methods of the BlockCipher class, thus answering the performance concern. This isn't to suggest there is anything wrong with just using the interface specific to the algorithm you know you want.

[vincenthz]

@TomMD good news !

[vincenthz]

@meteficha @snoyberg there's now a (weirdly called) keyOfCtx which take a Key and return the original key used. For the name, Key is going to be renamed to Ctx eventually when i get around to it.

[snoyberg]

Thanks!

[TomMD]

Following up: I have released a new version of crypto-api that includes the modes of operation as methods of the BlockCipher class. I had wanted to keep the code inside of Cipher.Modes, but found some corner cases with GHC and mutually recursive modules so had to do more significant refactoring.