[Haskell-cafe] Re: Crypto-API is stabilizing

2010-09-08 Thread Heinrich Apfelmus
Thomas DuBuisson wrote: Sorry, the example was all messed up, even if it did communicate what I wanted its just so broken I must fix. Slightly contrived example: buildAgreementMessage :: (Monad m, CryptoRandomGen g, ASymetricCipher k) = g - k - m (B.ByteString, (k,k), g)

[Haskell-cafe] Re: Crypto-API is stabilizing

2010-09-05 Thread Marcel Fourné
Thomas DuBuisson wrote: There is a blog on this [1], but the main points about the new class are: 1) Generates bytestrings, not Ints I like this one because it's semantically truer (tm). ;-) 2) Generalized PRNG construction and reseeding ...which takes the great burden off it's users

Re: [Haskell-cafe] Re: Crypto-API is stabilizing

2010-09-04 Thread Thomas DuBuisson
On Sat, Sep 4, 2010 at 3:23 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: 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

Re: [Haskell-cafe] Re: Crypto-API is stabilizing

2010-09-04 Thread Thomas DuBuisson
Sorry, the example was all messed up, even if it did communicate what I wanted its just so broken I must fix. Slightly contrived example: buildAgreementMessage :: (Monad m, CryptoRandomGen g, ASymetricCipher k) = g - k - m (B.ByteString, (k,k), g) buildAgreementMessages g k = do

Re: [Haskell-cafe] Re: Crypto-API is stabilizing

2010-09-03 Thread Sebastian Fischer
[CC'ing maintainer of MonadRandom] On Sep 3, 2010, at 1:59 AM, Thomas DuBuisson wrote: data Key = Key { encrypt :: B.ByteString - B.ByteString, decrypt :: B.ByteString - B.ByteString, keyLength :: BitLength, serialize ::

Re: [Haskell-cafe] Re: Crypto-API is stabilizing

2010-09-03 Thread Sebastian Fischer
On Sep 3, 2010, at 10:40 AM, Sebastian Fischer wrote: An advantage of using a MonadRandom class would be that the CryptoAPI would be independent of RandomGen or your new alternative. One could define random monads based on either. I was wrong. The MonadRandom class uses the Random class

Re: [Haskell-cafe] Re: Crypto-API is stabilizing

2010-09-03 Thread Thomas DuBuisson
If MR the more agreeable path then I'll do it, though this means I use the unholy fail function. You don't want to use monads because the Monad class defines the fail function? Sorry, I phrased this better on the blog comment. I don't want to use MonadRandom m = m (p,p) (MonadRandom + fail)

[Haskell-cafe] Re: Crypto-API is stabilizing

2010-09-02 Thread Thomas DuBuisson
Marcel noted: A central interface to get the output of a PRNG would be nice, preferably not constrained to Int like RandomGen. While BOS said: Also, don’t use RandomGen for your asymmetric PRNG. The default implementation in System.Random gives absolutely disastrous performance, and the

Re: [Haskell-cafe] Re: Crypto-API is stabilizing

2010-09-02 Thread Sebastian Fischer
On Aug 27, 2010, at 11:12 AM, Heinrich Apfelmus wrote: Is it actually necessary to use a type class here? The situation is very similar to Luke Palmer. Haskell Antipattern: Existential Typeclass. http://lukepalmer.wordpress.com/2010/01/24/ I suggest to use good old data types data

Re: [Haskell-cafe] Re: Crypto-API is stabilizing

2010-09-02 Thread Sebastian Fischer
On Sep 3, 2010, at 12:07 AM, Sebastian Fischer wrote: Why not use generateKeypair :: MonadRandom m = BitLength - m (Maybe (p,p)) Or if the choice to generate keys or not should solely depend on the BitLength (and not on the random generator): generateKeypair :: MonadRandom m =

Re: [Haskell-cafe] Re: Crypto-API is stabilizing

2010-09-02 Thread Thomas DuBuisson
On Thu, Sep 2, 2010 at 3:07 PM, Sebastian Fischer s...@informatik.uni-kiel.de wrote:  data Key = Key {               encrypt   :: B.ByteString - B.ByteString,               decrypt   :: B.ByteString - B.ByteString,               keyLength :: BitLength,               serialize :: B.ByteString}

Re: [Haskell-cafe] Re: Crypto-API is stabilizing

2010-09-02 Thread Daniel Peebles
Is there a reason this belongs under the Data. prefix? Why not break it out into Crypto, so future implementers of algorithms can also put their stuff under there. Everything at some level can be seen as Data, and it would be nice to start moving out of the overcrowded module hierarchy. On Fri,

[Haskell-cafe] Re: Crypto-API is stabilizing

2010-08-27 Thread Heinrich Apfelmus
Thomas DuBuisson wrote: class (Binary p, Serialize p) = AsymCipher p where generateKeypair :: RandomGen g = g - BitLength - Maybe ((p,p),g) encryptAsym :: p - B.ByteString - B.ByteString decryptAsym :: p - B.ByteString - B.ByteString asymKeyLength :: p - BitLength Is

[Haskell-cafe] Re: Crypto-API is stabilizing

2010-08-27 Thread Maciej Piechotka
On Mon, 2010-08-23 at 10:05 -0700, Thomas DuBuisson wrote: All, Crypto-API - a unified interface to which I hope hash and cipher algorithms will adhere - has recently gotten a reasonable amount of polish work. I continue to welcome all comments! A blog on its current interface is online

[Haskell-cafe] Re: Crypto-API is stabilizing

2010-08-26 Thread Thomas DuBuisson
class (Binary p, Serialize p) = AsymCipher p where generateKeypair :: RandomGen g = g - BitLength - Maybe ((p,p),g) encryptAsym :: p - B.ByteString - B.ByteString decryptAsym :: p - B.ByteString - B.ByteString asymKeyLength :: p - BitLength Regarding AsymCipher:

[Haskell-cafe] Re: Crypto-API is stabilizing

2010-08-24 Thread Marcel Fourné
Thomas DuBuisson wrote: [1] http://tommd.wordpress.com/2010/08/23/a-haskell-api-for-cryptographic-algorithms/ class (Binary p, Serialize p) = AsymCipher p where generateKeypair :: RandomGen g = g - BitLength - Maybe ((p,p),g) encryptAsym :: p - B.ByteString - B.ByteString