haskell-crypto / cryptonite Goto Github PK

    generate-param-odd:      FAIL
      *** Failed! Falsifiable (after 56 tests):
      TestDRG (14634184162,172342014,14634914744,16093274693,6665281464)
      Int0_2901 0
      Use --quickcheck-replay '55 TFGenR 000000005F255FBD000000000007A120000000000000DFA500000001B378B680 0 1152921504606846960 60 0' to reproduce.

Occurred with version 0.6.

Using Red Hat 4.1.2-54 x86_64, I have to compile cryptonite with --flag=-support_aesni (which is reasonable), and then fail with:

Last 10 lines of the build log ( /devshared/home/cortexdev/.cabal/logs/cryptonite-0.10.log ):
dist/build/cbits/blake2/sse/blake2bp.dyn_o: In function `fgetc_unlocked':
blake2bp.c:(.text+0xe90): multiple definition of `fgetc_unlocked'
dist/build/cbits/cryptonite_chacha.dyn_o:cryptonite_chacha.c:(.text+0xe60): first defined here
dist/build/cbits/blake2/sse/blake2bp.dyn_o: In function `getchar':
blake2bp.c:(.text+0xeb0): multiple definition of `getchar'
dist/build/cbits/cryptonite_chacha.dyn_o:cryptonite_chacha.c:(.text+0xe80): first defined here
dist/build/cbits/blake2/sse/blake2bp.dyn_o: In function `vprintf':
blake2bp.c:(.text+0xec0): multiple definition of `vprintf'
dist/build/cbits/cryptonite_chacha.dyn_o:cryptonite_chacha.c:(.text+0xe90): first defined here
collect2: ld returned 1 exit status
cabal: Error: some packages failed to install:
cryptonite-0.10 failed during the building phase. The exception was:

Would be nice if it worked, although I appreciate this is an ancient system.

Instead of using an explicit mutable context, and using IO, one can also hide everything in this Monad. I doubt this is better in all cases, but it might be more convenient in some. ekmett/bytes#25

https://buildd.debian.org/status/package.php?p=haskell-cryptonite&suite=sid

arm64, armel, armhf, mipsel, and ppc64el fail at blowfish64

https://wiki.debian.org/ArchitectureSpecificsMemo may contain a relevant commonality.

During development I'd like to be able to load a module in ghci and mess with the functions, but I've never been able to find a configuration that works (I'm using OSX). For example, trying to load the main library with cabal repl I get:

$ cabal repl cryptonite
Preprocessing library cryptonite-0.10...
GHCi, version 7.10.2: http://www.haskell.org/ghc/  :? for help
ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.2 for x86_64-apple-darwin):
    Loading temp shared object failed: dlopen(/var/folders/v9/36dyvmvd37vg__0jd5rlbyx80000gn/T/ghc2471_0/libghc_7.dylib, 5): Symbol not found: _cryptonite_aesni_decrypt_block128
  Referenced from: /var/folders/v9/36dyvmvd37vg__0jd5rlbyx80000gn/T/ghc2471_0/libghc_7.dylib
  Expected in: flat namespace
 in /var/folders/v9/36dyvmvd37vg__0jd5rlbyx80000gn/T/ghc2471_0/libghc_7.dylib

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Running cabal repl test-cryptonite works OK, but I'd like to be able to use ghci to run library functions directly, rather than via a test suite.

Has anyone been able to do this?

cryptonite_sysrand_init is not called anywhere afaict and it looks scarily wrong (out arg buf is unused, it just hashes the time and tosses the result).

I'm converting my code to cryptonite, and some of my tests are breaking. The first issue is based on the test data from the Appendix A1 of the JWE spec, which uses AES256 with GCM. The initialization vector has 12 bytes, but cryptonite's makeIV function returns Nothing if the data isn't a multiple of the block size. This seems to be a problem for things like GCM.

It would be neat to incorporate support for UMAC into cryptonite.

I've written a binding to a C implementation of this algorithm (as used in openssh) that I'd be happy to have incorporated into cryptonite with whatever changes were necessary. I've specialized the C implementation to the two MAC sizes that I needed for SSH (64 and 128) but the algorithm supports more sizes than that (and it might be desirable for cryptonite to do so).

Currently the implementation compiles against a C implementation of AES. I imagine that it'd be desirable to have it work against the existing implementation of AES in cryptonite if incorporated.

I'm opening this issue to start discussion on the topic.

Specification of UMAC:
https://www.ietf.org/rfc/rfc4418.txt

Current implementation:
https://github.com/glguy/ssh-hans/blob/eric/src/Crypto/MAC/UMAC.hs

https://tools.ietf.org/html/rfc2144

Citing from http://hydra.cryp.to/build/946016/nixlog/1/raw:

GHCi runtime linker: fatal error: I found a duplicate definition for symbol
   gf_mulx
whilst processing object file
   /nix/store/3lzzqvxrzmr5bgnvyjc0b6p9gq2jdd2b-haskell-cryptonite-0.4/lib/ghc-7.6.3/cryptonite-0.4/HScryptonite-0.4.o
This could be caused by:
   * Loading two different object files which export the same symbol
   * Specifying the same object file twice on the GHCi command line
   * An incorrect `package.conf' entry, causing some object to be
     loaded twice.
GHCi cannot safely continue in this situation.  Exiting now.  Sorry.

I'm using some of the functions in Crypto.PubKey.RSA, and wish to read and write PEM files compatible with openssl. I need functionality equivalent to these functions from OpenSSL.PEM:

• writePKCS8PrivateKey
• readPrivateKey
• writePublicKey
• readPublicKey

Are there functions in some library compatible with Crypto.PubKey.RSA to do this?

tracking issue for supporting more architectures
#24 #25

There was the handy function withRandomBytes, that can easily be added to cryptonite as well:

-- | generate @len random bytes and mapped the bytes to the function @f.
--                                                                                                    
-- This is equivalent to use Control.Arrow 'first' with 'randomBytesGenerate'
withRandomBytes :: DRG g => g -> Int -> (S.ByteString -> a) -> (a, g)
withRandomBytes rng len f = (f bs, rng')
  where (bs, rng') = randomBytesGenerate len rng

$ cabal install cryptonite-0.8
will install it successfully, but

$ cabal install cryptonite-0.9
will generate an error. It seems that the error is reproducible regardless of using cygwin console or cmd.exe.
I have attached log file cryptonite-0.9.log
cryptonite-0.9.txt

Environment:

• Windows 7
• HaskellPlatform 7.10.2-a-i386
• ghc - 7.10.2

Can you please let me if I want to provide more info?

The problem described in vincenthz/hs-crypto-random#10 seems to be in here too. It would be nice if the entropy would be mixed from different backends, maybe using XOR for every bit.

I'm using the function below for DSA signature verification; it would be nice if cryptonite could handle this case in some way.

+truncatingVerify :: (ByteArrayAccess msg, CHI.HashAlgorithm hash) => hash -> DSA.PublicKey -> DSA.Signature -> msg -> Bool
+truncatingVerify hashAlg pk (DSA.Signature r s) m
+    -- Reject the signature if either 0 < r < q or 0 < s < q is not satisfied.
+    | r <= 0 || r >= q || s <= 0 || s >= q = False
+    | otherwise                            = v == r
+    where (DSA.Params p g q) = DSA.public_params pk
+          y       = DSA.public_y pk
+          hm      = os2ip . dsaTruncate . BA.convert $ hashWith hashAlg m
+
+          w       = fromJust $ inverse s q
+          u1      = (hm*w) `mod` q
+          u2      = (r*w) `mod` q
+          v       = ((expFast g u1 p) * (expFast y u2 p)) `mod` p `mod` q
+          dsaTruncate bs = let lbs = BL.fromStrict bs in if countBits lbs > dsaQLen then B.take (fromIntegral dsaQLen `div` 8) bs else bs -- FIXME: uneven bits
+          dsaQLen = countBits . integerToBEBS $ q

CryptoFailable has a manually written Show instance that neither surrounds itself or its argument with parentheses correctly. I think that the correct solution is to just derive the correct instance, but for some reason the incorrect one is manually written.

I'll be happy to provide a patch if desired manually implementing the correct instance or deriving the Show instance if that would be helpful; I just need to know which you'd want.

In GCM, IVs are 12-bytes long, and if they're longer than that GHASH is run on them. This is implemented properly here, however, len will never be 12 when using makeIV or nullIV. Because of this, len will always be 16. While I can pass a raw 96-bit ByteString to aeadInit, I'd like to use ivAdd.

Is the plan to upgrade the x509 package to depend on cryptonite, or are ASN1Object instances going to be added somewhere so certificates can be made with cryptonite keys, or something else... ?

Hi,

should Crypto.Random.AESCtr be ported to cryptonite or is chacha the proposed replacement?

What about the urandom generator?

Thanks

The reason seems to be that the GCC flag -maes is not supported on the stock version of gcc on OSX 10.8.5, namely gcc 4.2.1. This flag doesn't seem to appear until GCC 5.2, so it would be good to detect the GCC version and add this flag only if -maes is supported.

jcheney$ sudo cabal install cryptonite --verbose
Reading available packages...
Choosing modular solver.
Resolving dependencies...
Ready to install cryptonite-0.5
Extracting
/Users/jcheney/Library/Haskell/repo-cache/hackage.haskell.org/cryptonite/0.5/cryptonite-0.5.tar.gz
to /tmp/cryptonite-0.5-48364...
Waiting for install task to finish...
Updating cryptonite.cabal with the latest revision from the index.
Configuring cryptonite-0.5...
creating /tmp/cryptonite-0.5-48364/cryptonite-0.5/dist/setup
creating /tmp/cryptonite-0.5-48364/cryptonite-0.5/dist
creating /tmp/cryptonite-0.5-48364/cryptonite-0.5/dist/setup
/Users/jcheney/.cabal/setup-exe-cache/setup-Cabal-1.18.1.4-x86_64-osx-ghc-7.8.3
configure --verbose=2 --ghc --prefix=/Users/jcheney/Library/Haskell
--bindir=/Users/jcheney/Library/Haskell/bin
--libdir=/Users/jcheney/Library/Haskell/ghc-7.8.3-x86_64/lib
--libsubdir=cryptonite-0.5 --libexecdir=/Users/jcheney/Library/Haskell/libexec
--datadir=/Users/jcheney/Library/Haskell/share
--datasubdir=ghc-7.8.3-x86_64/cryptonite-0.5
--docdir=/Users/jcheney/Library/Haskell/ghc-7.8.3-x86_64/lib/cryptonite-0.5/doc
--htmldir=/Users/jcheney/Library/Haskell/ghc-7.8.3-x86_64/lib/cryptonite-0.5/doc/html
--haddockdir=/Users/jcheney/Library/Haskell/ghc-7.8.3-x86_64/lib/cryptonite-0.5/doc/html
--sysconfdir=/Users/jcheney/Library/Haskell/etc --enable-library-profiling
--user --flags=-support_pclmuldq --flags=support_deepseq --flags=support_aesni
--flags=integer-gmp --extra-prog-path=/Users/jcheney/Library/Haskell/bin
--constraint=memory ==0.7 --constraint=integer-gmp ==0.5.1.0
--constraint=ghc-prim ==0.3.1.0 --constraint=deepseq ==1.3.0.2
--constraint=bytestring ==0.10.4.0 --constraint=base ==4.7.0.1 --disable-tests
--disable-benchmarks
Redirecting build log to {handle:
/Users/jcheney/.cabal/logs/cryptonite-0.5.log}
Building cryptonite-0.5...
creating /tmp/cryptonite-0.5-48364/cryptonite-0.5/dist/setup
/Users/jcheney/.cabal/setup-exe-cache/setup-Cabal-1.18.1.4-x86_64-osx-ghc-7.8.3
build --verbose=2
Redirecting build log to {handle:
/Users/jcheney/.cabal/logs/cryptonite-0.5.log}
Failed to install cryptonite-0.5
Last 10 lines of the build log ( /Users/jcheney/.cabal/logs/cryptonite-0.5.log ):
[88 of 93] Compiling Crypto.Cipher.Camellia ( Crypto/Cipher/Camellia.hs, dist/build/Crypto/Cipher/Camellia.p_o )
[89 of 93] Compiling Crypto.Cipher.DES ( Crypto/Cipher/DES.hs, dist/build/Crypto/Cipher/DES.p_o )
[90 of 93] Compiling Crypto.Cipher.TripleDES ( Crypto/Cipher/TripleDES.hs, dist/build/Crypto/Cipher/TripleDES.p_o )
[91 of 93] Compiling Crypto.PubKey.ECC.P256 ( Crypto/PubKey/ECC/P256.hs, dist/build/Crypto/PubKey/ECC/P256.p_o )
[92 of 93] Compiling Crypto.PubKey.Ed25519 ( Crypto/PubKey/Ed25519.hs, dist/build/Crypto/PubKey/Ed25519.p_o )
[93 of 93] Compiling Crypto.Cipher.AES ( Crypto/Cipher/AES.hs, dist/build/Crypto/Cipher/AES.p_o )
Building C Sources...
creating dist/build
/usr/bin/ghc -c -odir dist/build -Idist/build/autogen -Idist/build -Icbits -Icbits/ed25519 -optc-mssse3 -optc-maes -optc-DWITH_AESNI -optc-O2 -package-db dist/package.conf.inplace -package-id base-4.7.0.1-df210ede1eb79477fef5662549c32927 -package-id bytestring-0.10.4.0-4aa78c8ca7b6b65993eefc131f7d94fa -package-id deepseq-1.3.0.2-8f63133c1b77f3b3190f04893cf340e4 -package-id ghc-prim-0.3.1.0-954cb57749cf319beafdc89b3415422c -package-id integer-gmp-0.5.1.0-d42e6a7874a019e6a0d1c7305ebc83c4 -package-id memory-0.7-f369ee4f598039d1fc5f4df51fe53651 cbits/cryptonite_chacha.c
cc1: error: unrecognized command line option "-maes"
World file is already up to date.
cabal: Error: some packages failed to install:
cryptonite-0.5 failed during the building phase. The exception was:
ExitFailure 1

https://www.schneier.com/paper-twofish-paper.pdf

Another step towards #26:

--- haskell-cryptonite-0.6.orig/Crypto/Cipher/ChaChaPoly1305.hs
+++ haskell-cryptonite-0.6/Crypto/Cipher/ChaChaPoly1305.hs
@@ -108,5 +108,5 @@ finalize :: State -> Poly1305.Auth
 finalize (State _ macState aadLength plainLength) =
     Poly1305.finalize $ Poly1305.updates macState
         [ pad16 plainLength
-        , either (error "finalize: internal error") id $ P.fill 16 (P.putStorable (LE aadLength) >> P.putStorable (LE plainLength))
+        , either (error "finalize: internal error") id $ P.fill 16 (P.putStorable (toLE aadLength) >> P.putStorable (toLE plainLength))
         ]

With this and #30 applied, the test suite goes through. I hope it is comprehensive enough that this makes it likely that all endianness-bugs are fixed...

Digest can be partially evaluated, which presents several gotchas.

I had some simple code using cryptonite to get a hash:

md5 :: L.ByteString -> Digest MD5
md5 = hashLazy

md5hasher :: L.ByteString -> String
md5hasher = show . md5

md5hasher <$> L.readFile foo

This worked ok, running in constant space. But, it kept the file handle open until some later point when the hash was used (or possibly open past use until garbage collected). That turned out to prevent eg, deleting the file under windows (which doesn't allow open files to be deleted), which broke my test suite. So, I made what seemed like an innocuous change to "fix" that:

!hash <- md5hasher <$> L.readFile foo
return hash

But this version sometimes buffers the whole file content in memory. The bang pattern doesn't fully force the String, and so the Digest isn't fully forced either, and the hash can end up partially evaluated. In one case, hashing a 30 gb file resulted in a 30 gb malloc!

So, I had to do this (or could have used the NFData instance for Digest for same effect):

!hash <- md5hasher <$> L.readFile foo
return (length hash `seq` hash)

Which I think will avoid all problems, but was not easy to arrive at.

From my brief review of the API, I don't see any benefits to letting Digest be partially evaluated. So why not make the data type internally strict, or have hashLazy fully force it.

This seems like a reasonable thing to do, but I couldn't find any such function?

Citing from http://hydra.cryp.to/build/887540/log/raw:

Linking dist/build/test-cryptonite/test-cryptonite ...
/tmp/nix-build-haskell-cryptonite-0.1.drv-0/cryptonite-0.1/dist/build/libHScryptonite-0.1-7JEy8lnj4Z02y2at3QipFc-ghc7.10.1.so: undefined reference to `cryptonite_p256_point_mul'
/tmp/nix-build-haskell-cryptonite-0.1.drv-0/cryptonite-0.1/dist/build/libHScryptonite-0.1-7JEy8lnj4Z02y2at3QipFc-ghc7.10.1.so: undefined reference to `cryptonite_p256_modinv'
/tmp/nix-build-haskell-cryptonite-0.1.drv-0/cryptonite-0.1/dist/build/libHScryptonite-0.1-7JEy8lnj4Z02y2at3QipFc-ghc7.10.1.so: undefined reference to `cryptonite_p256_to_bin'
collect2: error: ld returned 1 exit status

Can this be derived directly from the existing Keccak implementation?

At https://buildd.debian.org/status/package.php?p=haskell-cryptonite&suite=sid you can see powerpc and s390x failing scrypt tests. These architectures are big-endian (as is mips, though that failed for other reasons).

cryptonite-0.6's test suite is expected to succeed in LTS 3.5, but it failed for me. Citing from http://hydra.cryp.to/build/1248057/nixlog/1/raw:

Running 1 test suites...
Test suite test-cryptonite: RUNNING...
cryptonite
  number
    num-bits:                OK
      +++ OK, passed 100 tests.
    num-bits2:               OK
      +++ OK, passed 100 tests.
    generate-param:          OK
      +++ OK, passed 100 tests.
    generate-param2:         FAIL
      *** Failed! Falsifiable (after 14 tests): 
      TestDRG (120,189,241,207,120)
      Int0_2901 0
      Use --quickcheck-replay '13 TFGenR 00000007B51EBF31000000000007A120000000000000DFC10000000F224D4A00 0 131064 17 0' to reproduce.

I implemented the AES Key Wrap algorithm (RFC 3394) using
cryptonite primitives and am wondering if upstream is receptive to
adopting the algorithm in cryptonite itself?

Current API:

aesKeyWrap
  :: (ByteArrayAccess m, ByteArray c, BlockCipher128 cipher)
  => cipher -> m -> c

aesKeyUnwrap
  :: (ByteArrayAccess c, ByteArray m, BlockCipher128 cipher)
  => cipher -> c -> Maybe m

It is defined for all BlockCipher128 because despite the name,
the algorithm only requires a 128-bit block size. It does not use
any feature of BlockCipher128 though - only ECB.

• CAST5 / CAST128 (RFC 2144)
• Twofish (https://www.schneier.com/paper-twofish-paper.pdf)

hi,

is there a simple example somewhere to do some file level CBC encryption ?

thank you !

Am I right, that forking the DRG is just not possible with every DRG in a pure way (i.e. without mixing entropy or using new entropy)?

If so, can you comment on how you envision it to be done? Maybe provide the building blocks to "purely" (but not referential transparent) mix entropy to get two generators or (better) provide a function to do that.

I might not have thought this out though.

On Mac OS X 10.7.5 (the last version runnable on my 2008 MacBook), cryptonite does not build because the C compiler on it does not know -maes.

I can still build cryptonite with -f -support_aesni, however. Maybe this should be mentioned in the README, or else a Mac OS X version check performed automatically.

I want to use CMAC (Cipher based Message Authenticaton Code) with cryptonite.
I implemented a naive implementation and test vectors.

May I create a pull request for this implementation?

khibino@ca0c383
khibino@b704f2c

CMAC
KAT - NIST test vectors
aes128
1: OK
2: OK
3: OK
4: OK
5: OK
6: OK
7: OK
aes192
1: OK
2: OK
3: OK
4: OK
5: OK
6: OK
7: OK
aes256
1: OK
2: OK
3: OK
4: OK
5: OK
6: OK
7: OK
Three Key TDEA
1: OK
2: OK
3: OK
4: OK
5: OK
6: OK (0.01s)
7: OK (0.01s)
Two Key TDEA
1: OK
2: OK
3: OK
4: OK
5: OK
6: OK (0.01s)
7: OK (0.01s)

I got both a user report for this problem, and had a build of my own fail. It appears like both cipher-aes and cryptonite provide the same linker name, which causes a conflict. Would it be possible to rename this in cryptonite so- while the transition to cryptonite is not yet complete- we can link in both libraries?

from build log:

149s] [99 of 99] Compiling Crypto.Cipher.AES ( Crypto/Cipher/AES.hs, dist/build/Crypto/Cipher/AES.p_o )
[ 185s]
[ 185s] In file included from cbits/blake2/blake2s.c:21:0:
[ 185s]
[ 185s] cbits/blake2/blake2-config.h:68:2:
[ 185s] error: #error "This code requires at least SSE2."
[ 185s] #error "This code requires at least SSE2."
[ 185s] ^
[ 185s]
[ 185s] In file included from cbits/blake2/blake2s.c:24:0:
[ 185s]
[ 185s] /usr/lib/gcc/i586-suse-linux/4.8/include/emmintrin.h:31:3:
[ 185s] error: #error "SSE2 instruction set not enabled"
[ 185s] # error "SSE2 instruction set not enabled"
[ 185s] ^
[ 185s] cbits/blake2/blake2s.c: In function ‘blake2s_compress’:
[ 185s]
[ 185s] cbits/blake2/blake2s.c:242:3:
[ 185s] error: unknown type name ‘__m128i’
[ 185s] __m128i row1, row2, row3, row4;
[ 185s] ^
[ 185s]
[ 185s] cbits/blake2/blake2s.c:243:3:
[ 185s] error: unknown type name ‘__m128i’
[ 185s] __m128i buf1, buf2, buf3, buf4;
[ 185s] ^
[ 185s]
[ 185s] cbits/blake2/blake2s.c:250:3:
[ 185s] error: unknown type name ‘__m128i’
[ 185s] __m128i ff0, ff1;
[ 185s] ^
[ 185s]
[ 185s] cbits/blake2/blake2s.c:278:3:
[ 185s] warning: implicit declaration of function ‘_mm_loadu_si128’ [-Wimplicit-function-declaration]
[ 185s] row1 = ff0 = LOADU( &S->h[0] );
[ 185s] ^
[ 185s]
[ 185s] cbits/blake2/blake2s.c:278:3: error: unknown type name ‘__m128i’
[ 185s]
[ 185s] cbits/blake2/blake2s.c:279:3:
[ 185s] error: unknown type name ‘__m128i’
[ 185s] row2 = ff1 = LOADU( &S->h[4] );
[ 185s] ^
[ 185s]
[ 185s] cbits/blake2/blake2s.c:280:3:
[ 185s] warning: implicit declaration of function ‘_mm_setr_epi32’ [-Wimplicit-function-declaration]
[ 185s] row3 = _mm_setr_epi32( 0x6A09E667, 0xBB67AE85, 0x3C6EF372, 0xA54FF53A );
[ 185s] ^
[ 185s]
[ 185s] cbits/blake2/blake2s.c:281:3:
[ 185s] warning: implicit declaration of function ‘_mm_xor_si128’ [-Wimplicit-function-declaration]
[ 185s] row4 = _mm_xor_si128( _mm_setr_epi32( 0x510E527F, 0x9B05688C, 0x1F83D9AB, 0x5BE0CD19 ), LOADU( &S->t[0] ) );
[ 185s] ^
[ 185s]
[ 185s] cbits/blake2/blake2s.c:281:3: error: unknown type name ‘__m128i’
[ 185s]
[ 185s] cbits/blake2/blake2s.c:282:3:
[ 185s] warning: implicit declaration of function ‘_mm_set_epi32’ [-Wimplicit-function-declaration]
[ 185s] ROUND( 0 );
[ 185s] ^
[ 185s]
[ 185s] cbits/blake2/blake2s.c:282:3:
[ 185s] warning: implicit declaration of function ‘_mm_add_epi32’ [-Wimplicit-function-declaration]
[ 185s]
[ 185s] cbits/blake2/blake2s.c:282:3:
[ 185s] warning: implicit declaration of function ‘_mm_srli_epi32’ [-Wimplicit-function-declaration]
[ 185s]
[ 185s] cbits/blake2/blake2s.c:282:3:
[ 185s] warning: implicit declaration of function ‘_mm_slli_epi32’ [-Wimplicit-function-declaration]
[ 185s]
[ 185s] cbits/blake2/blake2s.c:282:3:
[ 185s] warning: implicit declaration of function ‘_mm_shuffle_epi32’ [-Wimplicit-function-declaration]
[ 185s]
[ 185s] cbits/blake2/blake2s.c:282:3:
[ 185s] warning: implicit declaration of function ‘_MM_SHUFFLE’ [-Wimplicit-function-declaration]
[ 185s]
[ 185s] cbits/blake2/blake2s.c:292:3:
[ 185s] warning: implicit declaration of function ‘_mm_storeu_si128’ [-Wimplicit-function-declaration]
[ 185s] STOREU( &S->h[0], _mm_xor_si128( ff0, _mm_xor_si128( row1, row3 ) ) );
[ 185s] ^
[ 185s]
[ 185s] In file included from cbits/blake2/blake2s.c:38:0:
[ 185s]
[ 185s] cbits/blake2/blake2s-round.h:18:39:
[ 185s] error: ‘__m128i’ undeclared (first use in this function)
[ 185s] #define STOREU(p,r) _mm_storeu_si128((__m128i *)(p), r)
[ 185s] ^
[ 185s]
[ 185s] cbits/blake2/blake2s.c:292:3:
[ 185s] note: in expansion of macro ‘STOREU’
[ 185s] STOREU( &S->h[0], _mm_xor_si128( ff0, _mm_xor_si128( row1, row3 ) ) );
[ 185s] ^
[ 185s]
[ 185s] cbits/blake2/blake2s-round.h:18:39:
[ 185s] note: each undeclared identifier is reported only once for each function it appears in
[ 185s] #define STOREU(p,r) _mm_storeu_si128((__m128i *)(p), r)
[ 185s] ^
[ 185s]
[ 185s] cbits/blake2/blake2s.c:292:3:
[ 185s] note: in expansion of macro ‘STOREU’
[ 185s] STOREU( &S->h[0], _mm_xor_si128( ff0, _mm_xor_si128( row1, row3 ) ) );
[ 185s] ^
[ 185s]
[ 185s] cbits/blake2/blake2s-round.h:18:48:
[ 185s] error: expected expression before ‘)’ token
[ 185s] #define STOREU(p,r) _mm_storeu_si128((__m128i *)(p), r)
[ 185s] ^
[ 185s]
[ 185s] cbits/blake2/blake2s.c:292:3:
[ 185s] note: in expansion of macro ‘STOREU’
[ 185s] STOREU( &S->h[0], _mm_xor_si128( ff0, _mm_xor_si128( row1, row3 ) ) );
[ 185s] ^
[ 185s]
[ 185s] cbits/blake2/blake2s-round.h:18:48:
[ 185s] error: expected expression before ‘)’ token
[ 185s] #define STOREU(p,r) _mm_storeu_si128((__m128i *)(p), r)
[ 185s] ^
[ 185s]
[ 185s] cbits/blake2/blake2s.c:293:3:
[ 185s] note: in expansion of macro ‘STOREU’
[ 185s] STOREU( &S->h[4], _mm_xor_si128( ff1, _mm_xor_si128( row2, row4 ) ) );
[ 185s] ^
[ 185s] error: Bad exit status from /var/tmp/rpm-tmp.QzVuvW (%build)

I have seen this test failure:

    generate-param:          FAIL
      *** Failed! Falsifiable (after 72 tests): 
      TestDRG (10131262950327,4047807192587,4049022727728,12263005592284,10034241927390)
      Int0_2901 0
      Use --quickcheck-replay '71 TFGenR 2A35C0FFB673D1548CEF319A5BE591B6F8C90A7F3E3B4BAE04D9E9CF8A07B9C4 0 1023 10 0' to reproduce.

e.g. here and similarly here.

As these are quite different architectures it is likely that this is an architecture-independent bug.

The undefined trick is fine for internal code, feels but a little sketchy for user code. This also guarantees they are constants, and potentially opens the doors for compile-time-sized arrays etc.

112s] [99 of 99] Compiling Crypto.Cipher.AES ( Crypto/Cipher/AES.hs, dist/build/Crypto/Cipher/AES.p_o )
[ 139s]
[ 139s] In file included from cbits/blake2/blake2s.c:21:0:
[ 139s]
[ 139s] cbits/blake2/blake2-config.h:68:2:
[ 139s] error: #error "This code requires at least SSE2."
[ 139s] #error "This code requires at least SSE2."
[ 139s] ^
[ 139s]
[ 139s] cbits/blake2/blake2s.c:24:23:
[ 139s] fatal error: emmintrin.h: No such file or directory
[ 139s] compilation terminated.

I didn't get the error with 0.10, so this seems a new problem that first appears in 0.11:

cbits/ed448/x448.c:21:9:
     error: unknown type name '__uint128_t'
     typedef __uint128_t decaf_dword_t;
             ^

cbits/ed448/x448.c:22:9:
     error: unknown type name '__int128_t'
     typedef __int128_t decaf_sdword_t;
             ^
cbits/ed448/x448.c: In function 'gf_mul':

cbits/ed448/x448.c:83:48:
     warning: right shift count >= width of type [-Wshift-count-overflow]
         accum[X448_LIMBS-1] += accum[X448_LIMBS-2] >> LBITS;
                                                    ^

cbits/ed448/x448.c:85:48:
     warning: right shift count >= width of type [-Wshift-count-overflow]
         accum[X448_LIMBS/2] += accum[X448_LIMBS-1] >> LBITS;
                                                    ^

cbits/ed448/x448.c:87:45:
     warning: right shift count >= width of type [-Wshift-count-overflow]
             accum[j] += accum[(j-1)%X448_LIMBS] >> LBITS;
                                                 ^

cbits/ed448/x448.c:50:8:
     note: in definition of macro 'FOR_LIMB_U'
            op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; \
            ^

cbits/ed448/x448.c:87:45:
     warning: right shift count >= width of type [-Wshift-count-overflow]
             accum[j] += accum[(j-1)%X448_LIMBS] >> LBITS;
                                                 ^

cbits/ed448/x448.c:50:16:
     note: in definition of macro 'FOR_LIMB_U'
            op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; \
                    ^

cbits/ed448/x448.c:87:45:
     warning: right shift count >= width of type [-Wshift-count-overflow]
             accum[j] += accum[(j-1)%X448_LIMBS] >> LBITS;
                                                 ^

cbits/ed448/x448.c:50:24:
     note: in definition of macro 'FOR_LIMB_U'
            op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; \
                            ^

cbits/ed448/x448.c:87:45:
     warning: right shift count >= width of type [-Wshift-count-overflow]
             accum[j] += accum[(j-1)%X448_LIMBS] >> LBITS;
                                                 ^

cbits/ed448/x448.c:50:32:
     note: in definition of macro 'FOR_LIMB_U'
            op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; \
                                    ^

cbits/ed448/x448.c:87:45:
     warning: right shift count >= width of type [-Wshift-count-overflow]
             accum[j] += accum[(j-1)%X448_LIMBS] >> LBITS;
                                                 ^

cbits/ed448/x448.c:50:40:
     note: in definition of macro 'FOR_LIMB_U'
            op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; \
                                            ^

cbits/ed448/x448.c:87:45:
     warning: right shift count >= width of type [-Wshift-count-overflow]
             accum[j] += accum[(j-1)%X448_LIMBS] >> LBITS;
                                                 ^

cbits/ed448/x448.c:50:48:
     note: in definition of macro 'FOR_LIMB_U'
            op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; \
                                                    ^

cbits/ed448/x448.c:87:45:
     warning: right shift count >= width of type [-Wshift-count-overflow]
             accum[j] += accum[(j-1)%X448_LIMBS] >> LBITS;
                                                 ^

cbits/ed448/x448.c:50:56:
     note: in definition of macro 'FOR_LIMB_U'
            op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; \
                                                            ^

cbits/ed448/x448.c:87:45:
     warning: right shift count >= width of type [-Wshift-count-overflow]
             accum[j] += accum[(j-1)%X448_LIMBS] >> LBITS;
                                                 ^

cbits/ed448/x448.c:50:64:
     note: in definition of macro 'FOR_LIMB_U'
            op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; op;i++; \
                                                                    ^
cbits/ed448/x448.c: In function 'gf_canon':

cbits/ed448/x448.c:186:15:
     warning: right shift count >= width of type [-Wshift-count-overflow]
             carry >>= LBITS;
                   ^

cbits/ed448/x448.c:64:76:
     note: in definition of macro 'FOR_LIMB'
     #define FOR_LIMB(i,op) { unsigned int i=0; for (i=0; i<X448_LIMBS; i++)  { op; }}
                                                                                ^

cbits/ed448/x448.c:196:15:
     warning: right shift count >= width of type [-Wshift-count-overflow]
             carry >>= LBITS;
                   ^

cbits/ed448/x448.c:64:76:
     note: in definition of macro 'FOR_LIMB'
     #define FOR_LIMB(i,op) { unsigned int i=0; for (i=0; i<X448_LIMBS; i++)  { op; }}
                                                                                ^
cbits/ed448/x448.c: In function 'gf_deser':

cbits/ed448/x448.c:207:91:
     warning: right shift count >= width of type [-Wshift-count-overflow]
             for (bits += 8; (bits>=LBITS || i==X448_BYTES-1) && k<X448_LIMBS; bits-=LBITS, buf>>=LBITS) {
                                                                                               ^

cbits/ed448/x448.c:213:59:
     warning: right shift count >= width of type [-Wshift-count-overflow]
         FOR_LIMB(i, accum = (accum + s->limb[i] - P->limb[i]) >> WBITS );
                                                               ^

cbits/ed448/x448.c:64:76:
     note: in definition of macro 'FOR_LIMB'
     #define FOR_LIMB(i,op) { unsigned int i=0; for (i=0; i<X448_LIMBS; i++)  { op; }}
                                                                                ^

The one on hackage has the 0.8 changelog, the one in the GIT repository not.

Also the 0.8 tag is missing here.

The following code snippet yields different results for both packages.

import Crypto.Hash
import qualified Data.ByteString.Char8 as BSC

hash' bs = hash bs :: Digest MD5

show . hash' . BSC.pack $ "foo"
-- Returns
--   "\"acbd18db4cc2f85cedef654fccc4a4d8\"" for cryptonite
--     "acbd18db4cc2f85cedef654fccc4a4d8"   for cryptohash

This is probably due to the different Show instances:

Cryptonite:

instance Show (Digest a) where
    show (Digest bs) = show (B.convertToBase B.Base16 bs :: Bytes)

Cryptohash:

instance Show (Digest a) where
    show (Digest bs) = BC.unpack $ toHex bs

Will the instance in cryptonite stay as it is?
This would prevent cryptonite from being used as a drop-in replacement
for cryptohash, but maybe it isn't intended as such.

This is a step towards #26:

Edmund Grimley Evans suggested this patch, which, according to my testing, fixes the test suite failures of KDF/Scrypt:

diff --git a/cbits/cryptonite_scrypt.c b/cbits/cryptonite_scrypt.c
index fc3fd04..eaf28ac 100644
--- a/cbits/cryptonite_scrypt.c
+++ b/cbits/cryptonite_scrypt.c
@@ -46,7 +46,7 @@ static void blockmix_salsa8(uint32_t *in, uint32_t *out, uint3

 static inline uint64_t integerify(uint32_t *B, const uint32_t r)
 {
-       return le64_to_cpu(*((uint64_t *) (B + (2*r-1) * 16)));
+       return B[(2*r-1) * 16] | (uint64_t)B[(2*r-1) * 16 + 1] << 32;
 }

 static inline uint32_t load32(const uint8_t *p)

Please add Ord and Hashable instances for PublicKey and PrivateKey ytpes

It would be nice to create an empty Digest value. Is there any way you could expose this, or make Digest a monoid? Thank you for this project :)

Maybe there should be a note about the relationship of Cryptonite to CryptoHash https://github.com/vincenthz/hs-cryptohash especially because of overlapping module namespaces?

I'd like to use the HMAC functionality of cryptonite with an unsupported hash function (BLAKE2b/s), but I am unable to do so because the HashAlgorithm class is not exported.

A lot of the library functions which use "unsafe" functions like allocAndFreeze are tagged with the NOINLINE pragma. Is this a requirement? Are there general rules we can follow to know when this is required or not?

The ghc docs aren't very helpful here, indicating that this should never be needed "unless you're very cautious about code size", but I'm guessing that's not the reason in this case. Reading things like this wiki entry just confirm that it seems to be one of those "black art" areas of Haskell which are hard to find out more about :-).