AES-0.2.6: Fast AES encryption/decryption for bytestringsSource codeContentsIndex
Codec.Crypto.AES.IO
Description
Primitive (in IO) AES operations
Synopsis
newCtx :: Mode -> ByteString -> ByteString -> Direction -> IO AESCtx
newECBCtx :: ByteString -> Direction -> IO AESCtx
data Direction
= Encrypt
| Decrypt
data Mode
= ECB
| CBC
| CFB
| OFB
| CTR
data AESCtx
crypt :: AESCtx -> ByteString -> IO ByteString
Documentation
newCtxSource
:: Mode
-> ByteStringA 16, 24 or 32-byte AES key
-> ByteStringA 16-byte IV
-> Direction
-> IO AESCtx

Create an encryption/decryption context for incremental encryption/decryption

You may create an ECB context this way, in which case you may pass undefined for the IV

newECBCtxSource
:: ByteStringA 16, 24 or 32-byte AES key
-> Direction
-> IO AESCtx
Create a context for ECB, which doesn't need an IV
data Direction Source
Constructors
Encrypt
Decrypt
data Mode Source

Modes ECB and CBC can only handle full 16-byte frames. This means the length of every strict bytestring passed in must be a multiple of 16; when using lazy bytestrings, its component strict bytestrings must all satisfy this.

Other modes can handle bytestrings of any length. However, encrypting a bytestring of length 5 and then one of length 4 is not the same operation as encrypting a single bytestring of length 9; they are internally padded to a multiple of 16 bytes.

For OFB and CTR, Encrypt and Decrypt are the same operation. For CTR, the IV is the initial value of the counter.

Constructors
ECB
CBC
CFB
OFB
CTR
data AESCtx Source
crypt :: AESCtx -> ByteString -> IO ByteStringSource

Incrementally encrypt/decrypt bytestrings

crypt is definitely not thread-safe. Don't even think about it.

Produced by Haddock version 2.6.0