functions like OBJ_nid2sn() crash. That happens with
openssl engine -c, for example. It is enough to add following 3 lines to
objects.txt so that AES counter mode can be offloaded to the engine using
the workaround mentioned:
: AES-128-CTR : aes-128-ctr
hi,
I can see that EVP API doesn't support AES counter mode. My guess is
that it might be because of the fact that current EVP API doesn't have a
parameter for counter length. Is that the reason or is it something else?
the problem is that now one can't offload AES
On Tue, Apr 29, 2008, Jan Pechanec wrote:
hi,
I can see that EVP API doesn't support AES counter mode. My guess is
that it might be because of the fact that current EVP API doesn't have a
parameter for counter length. Is that the reason or is it something else?
Nobody
In message [EMAIL PROTECTED] on Thu, 03 Jul 2003 01:04:45 +0200, David Maurus
[EMAIL PROTECTED] said:
lists sorry for not answering before - I assumed that my position on
lists this was clear ;-).
Just wanted to make sure I hadn't misunderstood. Not being native
english has played tricks on me
I'd really like an answer to my question: does the patch I presented
to you constitue a good enough implementation of what has been
discussed and concluded here (basically, the patch makes AES-CTR
increase the IV with 1 after each block)?
Looks like it'll work for me too.
thanks,
-lee
I'd really like an answer to my question: does the patch I presented
to you constitue a good enough implementation of what has been
discussed and concluded here (basically, the patch makes AES-CTR
increase the IV with 1 after each block)?
If I don't have an answer soon, I'll have to decide for
In message [EMAIL PROTECTED] on Fri, 27 Jun 2003 09:56:38 +0200, Thierry Boivin
[EMAIL PROTECTED] said:
Thierry.Boivin Generalized approach : as differencies for the
Thierry.Boivin various applications are the way to build the IV, ie:
Thierry.Boivin nonce part /upper counter part / lower
Stephen Sprunk wrote:
Thus spake Richard Levitte - VMS Whacker [EMAIL PROTECTED]
lee_dilkie (the other thing to remember is that CTR can be used with
lee_dilkie any block cipher, it's not limited to AES)
Absolutely. However, since it's currently very obviously an
experimental field, and it
At 12:21 24/06/03 -0400, you wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David Maurus
Sent: Tuesday, June 24, 2003 7:29 AM
To: [EMAIL PROTECTED]
Subject: Re: AES counter mode
The easiest way to go about it would be to increment the user
Michael Sierchio wrote:
Completely. If we have confidence in the cipher and the secrecy
of the key, make the nonce all zeroes. There's good reason for not
doing this in the case of IPsec, but not for SSL/TLS.
In theory, you may be right ;-). But: For one, I think that it can't
hurt NOT to
Hello David,
David Maurus wrote:
Goetz Babin-Ebell wrote:
The application specifies 4 datas:
1. a step size
2. a bit mask.
3. a (optional) pointer to a function that is called if the
step bits that are not in the bit mask:
4. a (optional) pointer to a function doing the counting;
if
CTR mode offers very little advantage over CBC or CFB or OFB -- the
motivation for IPsec was very high speed, parallel encryption with
precomputation of the keystream (according to the Rt. Hon. Rev.
Bellovin, IETF Security Area co-chair).
A very important consideration for ultra high
Thus spake Thierry Boivin [EMAIL PROTECTED]
I agree with this approach which leaves the crypto library very open and
not to complex to manipulate, whatever the upper program to develop is.
Generalized approach : as differencies for the various applications are
the
way to build the IV, ie:
Thus spake Richard Levitte - VMS Whacker [EMAIL PROTECTED]
lee_dilkie (the other thing to remember is that CTR can be used with
lee_dilkie any block cipher, it's not limited to AES)
Absolutely. However, since it's currently very obviously an
experimental field, and it was originally
Thus spake David Maurus [EMAIL PROTECTED]
Stephen Sprunk wrote:
In the specification of CTR mode, as proposed for AES, you will find the
statement The number /nonce/ is incremented following each encryption.
I interpreted this to mean that the top 2^64 bits are to be incremented
for
each
Thus spake Michael Sierchio [EMAIL PROTECTED]
Argument: let's write an Internet draft that describes the use of AES CTR
mode in SSLv3/TLSv1. We can do it however we like, modulo the usual
criticism and review in the IETF working group(s).
Comments? Rich? Richard? Stephen?
I'm a bit more
: Thursday, June 26, 2003 10:57 AM
To: [EMAIL PROTECTED]
Subject: Re: AES counter mode
Thus spake Michael Sierchio [EMAIL PROTECTED]
Argument: let's write an Internet draft that describes the
use of AES CTR
mode in SSLv3/TLSv1. We can do it however we like, modulo the usual
criticism and review
In message [EMAIL PROTECTED] on Thu, 26 Jun 2003 12:55:22 -0400, Lee Dilkie
[EMAIL PROTECTED] said:
lee_dilkie What I was trying (unsuccessfully) to make a point
lee_dilkie about. Please don't code up your CTR mode to *just* do the
lee_dilkie NIST or Ipsec version of CTR mode. Please code a
Hello Richard,
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED]
on Thu, 26 Jun 2003 12:55:22 -0400, Lee Dilkie [EMAIL PROTECTED] said:
OK, I've been follownig this discussion for a while, and it's time I
ake action. Basically, to provide for all the current and future ways
of
Steven,
Stephen Sprunk wrote:
Thus spake David Maurus [EMAIL PROTECTED]
I assume that 'number /nonce/' should mean the result of the
concatenated parts of the IV.
No, in the proposal to NIST (by Lipmaa, Rogaway and Wagner), 'nonce' refers
to the top 64 bits and 'ctr' refers to the lower
Gtz Babin-Ebell wrote:
The application specifies 4 datas:
1. a step size
2. a bit mask.
3. a (optional) pointer to a function that is called if the
step bits that are not in the bit mask:
4. a (optional) pointer to a function doing the counting;
if (pCounter-Range)
return
Stephen Sprunk wrote:
I'm a bit more ambitious... We should specify NIST-style CTR mode for all
octet stream applications within the IETF's domain, with SSL/TLS as an
example. For record-based systems, I don't know if NIST-style or
IPsec-style would be more appropriate :-(
There is no such
Richard Levitte - VMS Whacker wrote:
OK, I've been follownig this discussion for a while, and it's time I
ake action. Basically, to provide for all the current and future ways
of handling the IV, I can see three alternatives:
- have the application provide a function that manipulates the IV.
-
In message [EMAIL PROTECTED] on Thu, 26 Jun 2003 13:31:37 -0700, Michael Sierchio
[EMAIL PROTECTED] said:
kudzu Richard Levitte - VMS Whacker wrote:
kudzu
kudzu OK, I've been follownig this discussion for a while, and it's time I
kudzu ake action. Basically, to provide for all the current
Richard Levitte - VMS Whacker wrote:
Whatever, I used the terms like this:
- IV is a bitstring of some sort (possibly random), of the same size
as the crypto algorithm block. In the AES case, it would be 128
bits.
- For CTR mode, the counter is a part of the IV. The rest of the IV
is
Stephen Sprunk wrote:
In the specification of CTR mode, as proposed for AES, you will find the
statement The number /nonce/ is incremented following each encryption. I
interpreted this to mean that the top 2^64 bits are to be incremented for
each successive block, and this is how I implemented
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David Maurus
Sent: Tuesday, June 24, 2003 7:29 AM
To: [EMAIL PROTECTED]
Subject: Re: AES counter mode
The easiest way to go about it would be to increment the user
supplied
IV by 1 for each encrypted
Hi,
http://archives.seul.org/mixminion/cvs/May-2002/msg00072.html shows that the problem
seems to have been submitted to the openssl team one year ago.I agree with Nick and go
to the same conclusion : as the openssl aes counter mode routines wants to count by
2**64 instead of by 1, the current
In message [EMAIL PROTECTED] on Mon, 23 Jun 2003 18:22:37 +0200, Thierry Boivin
[EMAIL PROTECTED] said:
Thierry.Boivin My understanding of this one is (in a practical perspective) is :
Thierry.Boivin calling programs maintain a 64 bit long nonce counter. This counter is
to be incremented by
but this has performance
impacts.
-lee
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Richard
Levitte - VMS
Whacker
Sent: Monday, June 23, 2003 12:36 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: AES counter mode
64 zero-bits.) The number nonce is incremented
following each encryption.
Using AES Counter Mode With IPsec ESP - This mandates a 32-bit counter,
requiring rekeying after 2^48 octets of stream material.
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-04.txt
Argument: let's write
Thierry Boivin [EMAIL PROTECTED] said:
Thierry.Boivin My understanding of this one is (in a practical perspective) is :
Thierry.Boivin calling programs maintain a 64 bit long nonce counter.
This is not correct - to quote from the (btw excellent) new book from Bruce
Schneier and Neils Fergusson
Michael Sierchio wrote:
Using AES Counter Mode With IPsec ESP - This mandates a 32-bit counter,
requiring rekeying after 2^48 octets of stream material.
Ah, this is interesting. Considering that OpenSSL is not only used for
SSL / TLS encryption, and the mentioned RFC proposes to use a 32 bit
Thus spake Thierry Boivin [EMAIL PROTECTED]
http://archives.seul.org/mixminion/cvs/May-2002/msg00072.html shows
that the problem seems to have been submitted to the openssl team one
year ago.I agree with Nick and go to the same conclusion : as the
openssl aes counter mode routines wants
At 07:48 10/06/03 -0700, you wrote:
Thierry Boivin wrote:
I agree with you about the way to build the initial ctr value from the nonce
value. My question is different : whithin the encryption of a whole plaintext
message (so a big block to be divided into 128 bit length blocks) , why to
the actual increment by 2^64 come from ?
Read the documents on AES counter mode. The counter is a 64-bit
counter but the blocksize is 128, and the convention is that the
counter is a Big Endian number with only the MSW used.
[from Lipmaa, Rogaway Wagner]
In the recommended usage scenario
Thierry Boivin wrote:
I agree with you about the way to build the initial ctr value from the nonce value. My question is different : whithin the encryption of a whole plaintext message (so a big block to be divided into 128 bit length blocks) , why to increment ctr by 2^64 instead of 1 from
Hello,
I am trying to play with AES crypto in counter mode. Using the crypto library against
reference vectors found in IPSec RFC fails until the incrementation function
(AES_ctr128_inc()) is modified in order to get a +1 step instead of a +2^64 step.
Where does the actual increment by 2^64
increment by 2^64 come from ?
Read the documents on AES counter mode. The counter is a 64-bit
counter but the blocksize is 128, and the convention is that the
counter is a Big Endian number with only the MSW used.
[from Lipmaa, Rogaway Wagner]
In the recommended usage scenario, the party
Stephen Sprunk wrote:
If we document that *num must always be zero on first use (not sure
how I can assert() that), is there any bug that needs fixing?
Yes, the sample code I included in a previous post demonstrates the bug
despite num being zero on first use.
Matt
In message [EMAIL PROTECTED] on Tue, 30 Jul 2002 16:18:07
PDT, Matt Piotrowski [EMAIL PROTECTED] said:
matt.piotrowski num could point to a value out of that range if it
matt.piotrowski is not initialized before the first call to
matt.piotrowski AES_ctr128_encrypt(). The fix for this is to
In message [EMAIL PROTECTED] on Tue, 30 Jul 2002 14:04:21
PDT, Matt Piotrowski [EMAIL PROTECTED] said:
matt.piotrowski I think there's a bug in the AES counter mode
matt.piotrowski implementation: if you pass a non-zero counter offset
matt.piotrowski to AES_ctr128_encrypt() (through the num
Richard Levitte - VMS Whacker wrote:
How could num (or n, inside AES_ctr128_encrypt() ever have a value
that isn't between 0 (included) and AES_BLOCK_SIZE (excluded),
It's even smaller than that. CTR mode is defined as a BIG-ENDIAN
128-bit number (AES only has one block size) 0 = n = 2^64-1
On Tuesday 30 July 2002 02:54 pm, Richard Levitte - VMS Whacker wrote:
How could num (or n, inside AES_ctr128_encrypt() ever have a value
that isn't between 0 (included) and AES_BLOCK_SIZE (excluded), unless
you do something stupid with num between calls? Make note of the
following
Thus spake John Viega:
Additionally, with respect to counter mode, it might be best to
implement external to the EVP proper interface, just like HMAC. There
are a few issues I see that make counter mode a bit different from
other modes:
1) You should be able to insert your own function
When I looked at the AES API, it looked like there was no way to
specify a block size independently of the key size. Is that
intentional?
Additionally, with respect to counter mode, it might be best to
implement external to the EVP proper interface, just like HMAC. There
are a few issues I
Thus spake John Viega:
When I looked at the AES API, it looked like there was no way to
specify a block size independently of the key size. Is that
intentional?
The NIST FIPS specifies AES with a 128-bit block size. Rijndael can
be used in many other ways, but there is a significant
John Viega wrote:
Additionally, with respect to counter mode, it might be best to
implement external to the EVP proper interface, just like HMAC. There
are a few issues I see that make counter mode a bit different from
other modes:
1) You should be able to insert your own function for
48 matches
Mail list logo
