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?
>
Nobo
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
>>experimenta
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 originall
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
> 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 perfo
David Maurus wrote:
In theory, you may be right ;-). But: For one, I think that it can't
hurt NOT to have complete confidence in the cipher. I prefer to err on
the safe side. E.G. if an attack profits from having the same plaintext
encrypted twice with different cipher texts, we would encounter
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 (pCounter
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 h
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
>>
>
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 some
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 c
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.
- ha
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 thing
Götz 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 pCounter->Range(pCo
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 low
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 way
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 cod
TECTED] Behalf Of Stephen Sprunk
> Sent: 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
>
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
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
fo
> -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
>
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
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
David Maurus wrote:
The counter would overflow after the transmission of 2**32 blocks, a
block being 2**4 octets (128 bits, 16 octets), so rekeying should be
necessary after 2**36 octets (= 64 GB).
Thanks for the arithmetic lesson ;-) Caffeine deficiency here
Argument: let's write an Int
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
cou
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 Ferguss
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 fac
n and that was to have the
application provide the increment value as well 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
&
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
ent +2**64 operator.
Thierry Boivin
>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
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
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 b
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 ?
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 fun
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 funct
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 per
39 matches
Mail list logo
