tommd / cipher-aes128 Goto Github PK

Based on cipher-aes, but using a crypto-api interface and providing resulting IVs for each mode

License: Other

Haskell 24.14% C 75.86%

cipher-aes128's Introduction

AES and various modes

This package, available on hackage, implements AES and various modes of operation. Despite the name, it provides AES-192 and 256 as well.

While it original started as a fork of the cipher-aes package to test a performance improvement, this package continues to be maintained due to my preference for the API (for example, also this) and the idea that faster C code will eventually be adopted.

Use

Most users will want the crypto-api interface to generate keys and encrypt/decrypt data:

{-# LANGUAGE OverloadedStrings #-}
import Data.ByteString
import Crypto.Cipher.AES128 (AESKey128)
import Crypto.Classes (buildKeyIO, ctr, unCtr, zeroIV)

main =
 do k <- buildKeyIO :: IO AESKey128
    let myMessage            = "Some message or another"
        (ciphertext,_nextIV) = ctr k zeroIV myMessage
        (myMessage',_nextIV) = unCtr k zeroIV ciphertext
    print (unpack myMessage)
    print (unpack ciphertext)
    print $ myMessage == myMessage'

Unless you need GCM in which case, as of writing, you'll need to use makeGCMCtx, encryptGCM and decryptGCM.

cipher-aes128's People

Contributors

Stargazers

Watchers

Forkers

acw phadej dmjio mdeltax felixonmars dten laurynaspukenas manish364824 jsynacek tripshot

cipher-aes128's Issues

Version 0.5 is incompatible with cipher-aes

If you try to link a program that (indirectly) depends on both cipher-aes and cipher-aes128 you get a linker error due to duplicate C symbols. In particular for the symbol: _aes_gcm_aad.

The issue seems to be that aes_gcm_aad was declared static in previous versions, but now it's an exported C symbol.

Build fails with GHC 7.6 Travis instances

My turn to leave a bug for you! HAHAHAHA!!!11!

In trying to hook up RSA to Travis, I'm running into the following issue:

Building cipher-aes128-0.7...
Failed to install cipher-aes128-0.7
Last 10 lines of the build log ( /home/travis/.cabal/logs/cipher-aes128-0.7.log ):
Not in scope: B.unsafePackMallocCStringLen' Perhaps you meant one of these: B.unsafePackMallocCString' (imported from Data.ByteString.Unsafe),
B.unsafePackCStringLen' (imported from Data.ByteString.Unsafe) Crypto/Cipher/AES128.hs:262:19: Not in scope:B.unsafePackMallocCStringLen'
Perhaps you meant one of these:
B.unsafePackMallocCString' (imported from Data.ByteString.Unsafe), B.unsafePackCStringLen' (imported from Data.ByteString.Unsafe)

Which suggests that one or both of us should be modifying our base bytestring dependency.

benchmark build failure (different one)

As seen on the stackage build server:

[3 of 3] Compiling Main             ( Benchmark/bench.hs, dist/build/bench/bench-tmp/Main.o )

Benchmark/bench.hs:15:14: error:
    Not in scope: ‘AES.initAES’
    No module named ‘AES’ is imported.

I was able to reproduce the same error locally like so:

$ stack unpack cipher-aes128-0.7.0.2
$ cd cipher-aes128-0.7.0.2/
$ stack init --resolver nightly-2016-08-31
$ stack bench

Extract the C library to another repo

The C library could be rather useful stand alone, particularly if this backend work gets done. Extract it into a submodule.

Version 0.6.2 is incompatible with cipher-aes

I'm not sure this is related to cipher-aes but it looks similar to #5 so I assume it is.

I get the following link error:

$ cabal build
...
Loading package cipher-aes-0.2.6 ... linking ... done.
...
Loading package cipher-aes128-0.6.2 ... 

GHCi runtime linker: fatal error: I found a duplicate definition for symbol
   initialize_hw
whilst processing object file
   /home/bas/dev/erudify/.cabal-sandbox/lib/x86_64-linux-ghc-7.6.3/cipher-aes128-0.6.2/libHScipher-aes128-0.6.2.a
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.

Fix key serialization

It appears that key serialization is broken. Fix it.

Support for Cabal 3.6

Hi @TomMD!
Could the upper bound on Cabal 3.5 be lifted to allow for Cabal 3.6?. :-)

Support for GHC 8.10

Looks like Hackage revision has support for GHC 8.8, could we get the same for 8.10 please?

Adjust Backends

Add a STM32-F4 crypto unit backend.
Consider an ARM NEON backend or other mainstream ARM processor
Move to higher performance Intel AES NI code (particularly for GCM). This can be found in Intel's PDF but is not easy to extract into compiling code.
Move to Gladman AES for the ANSI-C.
Generalize the pointer rewriting to support numerous backends.

benchmark build failure

The benchmarks for this package has been disabled in stackage because of this issue. If a fix is published to hackage can you please ping me?

Thanks!

> /tmp/stackage-build8/cipher-aes128-0.7.0.1$ runghc -clear-package-db -global-package-db -package-db=/var/stackage/work/builds/nightly/pkgdb Setup configure --enable-benchmarks --package-db=clear --package-db=global --package-db=/var/stackage/work/builds/nightly/pkgdb --libdir=/var/stackage/work/builds/nightly/lib --bindir=/var/stackage/work/builds/nightly/bin --datadir=/var/stackage/work/builds/nightly/share --libexecdir=/var/stackage/work/builds/nightly/libexec --sysconfdir=/var/stackage/work/builds/nightly/etc --docdir=/var/stackage/work/builds/nightly/doc/cipher-aes128-0.7.0.1 --htmldir=/var/stackage/work/builds/nightly/doc/cipher-aes128-0.7.0.1 --haddockdir=/var/stackage/work/builds/nightly/doc/cipher-aes128-0.7.0.1 --flags=
Configuring cipher-aes128-0.7.0.1...
Warning: Packages using 'cabal-version: >= 1.10' must specify the
'default-language' field for each component (e.g. Haskell98 or Haskell2010).
If a component uses different languages in different modules then list the
other ones in the 'other-languages' field.
> /tmp/stackage-build8/cipher-aes128-0.7.0.1$ runghc -clear-package-db -global-package-db -package-db=/var/stackage/work/builds/nightly/pkgdb Setup build
Result of NI Intrinsics Test: True
Building cipher-aes128-0.7.0.1...
Preprocessing library cipher-aes128-0.7.0.1...
[1 of 2] Compiling Crypto.Cipher.AES128.Internal ( Crypto/Cipher/AES128/Internal.hs, dist/build/Crypto/Cipher/AES128/Internal.o )
[2 of 2] Compiling Crypto.Cipher.AES128 ( Crypto/Cipher/AES128.hs, dist/build/Crypto/Cipher/AES128.o )
Preprocessing benchmark 'bench' for cipher-aes128-0.7.0.1...
[1 of 3] Compiling Crypto.Cipher.AES128.Internal ( Crypto/Cipher/AES128/Internal.hs, dist/build/bench/bench-tmp/Crypto/Cipher/AES128/Internal.o )
[2 of 3] Compiling Crypto.Cipher.AES128 ( Crypto/Cipher/AES128.hs, dist/build/bench/bench-tmp/Crypto/Cipher/AES128.o )
[3 of 3] Compiling Main             ( Benchmark/bench.hs, dist/build/bench/bench-tmp/Main.o )

Benchmark/bench.hs:22:53: error:
    Ambiguous occurrence ‘encryptGCM’
    It could refer to either ‘Crypto.Cipher.AES128.encryptGCM’,
                             imported from ‘Crypto.Cipher.AES128’ at Benchmark/bench.hs:1:1-27
                             (and originally defined at Crypto/Cipher/AES128.hs:196:1-10)
                          or ‘Crypto.Cipher.AES.encryptGCM’,
                             imported from ‘Crypto.Cipher.AES’ at Benchmark/bench.hs:2:1-24

Broken Build System

This build system is broken in several ways:

It does not work on most Macs, likely in part due to the assumption of GCC. Move to a later stage to test -maes, a stage where we have the compiler field filled in.
Make sure you're testing the compiler's support for -maes and not the host's support for AES-NI. If we are testing the host then code compiled on NI machines will have NI instructions but not code compiled on older machines (so moving binaries to NI machines wouldn't get an NI benefit).

Build failure with GHC 7.6

This is likely a missing lower bound on bytestring, but it's showing up as my GHC 7.6 Travis builds failing. The error message is:

Crypto/Cipher/AES128.hs:208:14:
    Not in scope: `B.unsafePackMallocCStringLen'
    Perhaps you meant one of these:
      `B.unsafePackMallocCString' (imported from Data.ByteString.Unsafe),
      `B.unsafePackCStringLen' (imported from Data.ByteString.Unsafe)

Crypto/Cipher/AES128.hs:209:14:
    Not in scope: `B.unsafePackMallocCStringLen'
    Perhaps you meant one of these:
      `B.unsafePackMallocCString' (imported from Data.ByteString.Unsafe),
      `B.unsafePackCStringLen' (imported from Data.ByteString.Unsafe)

Crypto/Cipher/AES128.hs:261:19:
    Not in scope: `B.unsafePackMallocCStringLen'
    Perhaps you meant one of these:
      `B.unsafePackMallocCString' (imported from Data.ByteString.Unsafe),
      `B.unsafePackCStringLen' (imported from Data.ByteString.Unsafe)

Crypto/Cipher/AES128.hs:262:19:
    Not in scope: `B.unsafePackMallocCStringLen'
    Perhaps you meant one of these:
      `B.unsafePackMallocCString' (imported from Data.ByteString.Unsafe),
      `B.unsafePackCStringLen' (imported from Data.ByteString.Unsafe)
cabal: Error: some packages failed to install:
cipher-aes128-0.7 failed during the building phase. The exception was:

Fails to compile with GHC 7.0.4 and GHC 7.2.2

Judging from

https://ghc.haskell.org/~hvr/buildreports/cipher-aes128.html

this looks a lot like haskell/entropy#24