On Tue, 29 Apr 2008, Dr. Stephen Henson wrote:
the problem is that now one can't offload AES counter modes to the
engine unless the application itself specifies its own EVP functions and
structures. However, even then, counter mode IDs and names are missing from
obj*.h files so
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 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
Date: Wed, 11 Jun 2003 08:06:34 +0200
To: [EMAIL PROTECTED]
From: Thierry Boivin [EMAIL PROTECTED]
Subject: Re: AES counter mode
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
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
Lee Dilkie wrote:
I don't have experience with counter mode for SSL (if there is even such a
beast) or the NIST mode you are referencing (I believe Ipsec was looking at
that mode a few months ago) but I do have experience with counter mode for
SRTP (secure RTP; encryption of media streams). In
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 to
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
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 block to block ?
My
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
Thierry Boivin wrote:
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
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
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
37 matches
Mail list logo
