Take me over?
- SEE ALSO
- VERSION CONTROL
- COPYRIGHT & LICENSE
Crypt::EAX - Encrypt and authenticate data in EAX mode
use Crypt::EAX; my $c = Crypt::EAX->new( key => $key, cipher => "Crypt::Rijndael", header => $header, # optional nonce => $nonce, # optional but reccomended fatal => 1, ); my $ciphertext = $c->encrypt( $message ); $ciphertext ^= "moose"; # corrupt it $c->decrypt( $ciphertext ); # dies $ciphertext ^= "moose"; # xor is reversible is( $c->decrypt( $ciphertext ), $msg );
EAX is a cipher chaining mode with integrated message authentication. This type of encryption mode is called AEAD, or Authenticated Encryption with Associated Data.
The purpuse of AEAD modes is that you can safely encrypt and sign a value with a shared key. The message will not decrypt if it has been tampered with.
There are various reasons why just
encrypt(mac($message)) is not safe, but I don't exactly know them since I'm not a crptographer. For more info use The Oracle Google.
Read more about EAX AEAD here:
Defaults to Crypt::Rijndael. Likewise passed verbatim.
Whether or not failed verification dies or returns a false value.
Additional data to be authenticated but not encrypted.
Note that it's also possible to incrementally add the header using
headeroption is passed instead then
add_headerwill be called with it as an argument every time
This will not be included in the resulting ciphertext, but the ciphertext must be authenticated against it.
Presumably you are supposed to encode the ciphertext and header together in your message.
This is the Associated Data part of AEAD.
Be careful if you deconstruct the message naively, like this:
my ( $header, $ciphertext ) = unpack("N/a a*", $message);
since you are inherently trusting the input data already, before it's been verified (the N/ part can be altered, and though knowing Perl this is probably safe, I wouldn't count on it). The specific attack in this case is if a large number is encoded by the attacker in the N field then it could trick your program into trying allocate 4GB of memory in this particular example.
At any rate do not trust the header till the ciphertext has been successfully decrypted.
The nonce to use for authentication. Should be unique. See http://en.wikipedia.org/wiki/Cryptographic_nonce.
It is OK to pass this along with the ciphertext, much like the salt bit in
An empty value is allowed and is in fact the default, but this is not safe against replay attacks.
- new %args
Instantiate a new Crypt::EAX object.
- encrypt $plaintext
- decrypt $ciphertext
Single step encryption/decryption.
The tag is appended to the ciphertext.
- encrypt_parts $plaintext
Returns the ciphertext and tag as separate tags.
- decrypt_parts $ciphertext, $tag
Decrypts and verifies the message.
- start $mode
- finish ?$tag
If encrypting, returns the tag.
If decrypting, checks that $tag is equal to the calculated tag.
- add_encrypt $text
- add_decrypt $ciphertext
Streaming mode of operation. Requires a call to
finishafter. Used by
- add_header $header
Add header data that will be authenticated as well. See
headerfor more details.
Called when verification fails. Dies when
fatalis set, returns a false value otherwise.
Consider disallowing an empty nonce.
Can anyone advise on this?
This module is maintained using Darcs. You can get the latest version from http://nothingmuch.woobling.org/code, and use
darcs send to commit changes.
Yuval Kogman <email@example.com>
Copyright (c) 2007 Yuval Kogman. All rights reserved This program is free software; you can redistribute it and/or modify it under the terms of the MIT license or the same terms as Perl itself.