[Haskell-cafe] Re: Crypto-API is stabilizing
Heinrich Apfelmus
apfelmus at quantentunnel.de
Sat Sep 4 06:23:31 EDT 2010
Sebastian Fischer wrote:
> Thomas DuBuisson wrote:
>
>>>> data Key = Key {
>>>> encrypt :: B.ByteString -> B.ByteString,
>>>> decrypt :: B.ByteString -> B.ByteString,
>>>> keyLength :: BitLength,
>>>> serialize :: B.ByteString}
>>>>
>>>> rsa :: RandomGen g => BitLength -> g -> ((Key,Key), g)
>>
>> One reason against this is simply that all the other constructs
>> (block/stream cipher, hashes) are classes, it would be odd for there
>> to be a single exception.
Chances are that you can express them like this as well. :)
>> A better reason is the data structure has
>> no way to implement generateKeyPair.
That's a non-problem: each algorithm (RSA, DSA, ...) implements a
function with the same type as generateKeyPair . Compare
rsa :: RangomGen g => BitLength -> g -> ((Key,Key), g)
vs
((k1 :: RSA, k2), g') = generateKeyPair g
You always have to write down the name of the algorithm ("RSA") when
using generateKeyPair , so you may as well drop it entirely.
> Also, the type-class approach is extensible in that new operations (for
> example for signing) can be added via subclasses. Later extending the
> key type above requires nesting.
That's an argument in favor of type classes, indeed. However, if the
extension applies to *all* key types, i.e. if you could merge the
subclasses into the superclass, then you can add the new fields to the
Key type. If the record fields are read-only, this will not break
backwards compatibility.
> In general, I like this approach, but what are
>
> encrypt privateKey
>
> or
>
> decrypt publicKey
>
> supposed to do? A type-class solution also does not *prevent*
> programmers to perform such non-sensical calls, but the data-type
> solution *forces* programmers to provide non-sensical encrypt and
> decrypt functions when creating the public and private keys.
>
> Would it be desirable to prohibit such calls using the type system?
Unless the implementor of a new encryption algorithm uses different
types to distinguish between public and private key, the type class
approach forces him to provide non-sensical encrypt and decrypt
functions, too.
Regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
More information about the Libraries
mailing list