Re: AES counter mode

2003-06-26 Thread Michael Sierchio
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 kind of random bits (a nonce).
Those are the conditions I'm working from.  Makes sense?
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.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: AES counter mode

2003-06-26 Thread Richard Levitte - VMS Whacker
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 and future ways
kudzu> > of handling the IV, I can see three alternatives:
kudzu> > 
kudzu> > - have the application provide a function that manipulates the IV.
kudzu> > - have the application specify exactly which part of the IV is the
kudzu> >   actual counter (in bit positions, or would byte positions be
kudzu> >   enough?).
kudzu> > - a combination of the two (that would make our code extract the
kudzu> >   counters bits and only give those to the provided function, which
kudzu> >   then does the increment in any way it wishes).
kudzu> 
kudzu> There's no need for an IV for SSL/TLS encryption with AES CTR mode.
kudzu> All that's needed is a counter, and a mechanism to prevent using
kudzu> more than 2^38 or so bytes of keystream without changing the key.

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 kind of random bits (a nonce).

Those are the conditions I'm working from.  Makes sense?

kudzu> > lee_dilkie> (the other thing to remember is that CTR can be used with
kudzu> > lee_dilkie> any block cipher, it's not limited to AES)
kudzu> > 
kudzu> > Absolutely.  
kudzu> 
kudzu> Not quite.  You want to be sure to use block ciphers that are
kudzu> differentially strong.  AES is particularly well-suited.

Point.

-- 
Richard Levitte   \ Tunnlandsvägen 3  \ [EMAIL PROTECTED]
[EMAIL PROTECTED]  \ S-168 36  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: AES counter mode

2003-06-26 Thread Michael Sierchio
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.
- have the application specify exactly which part of the IV is the
  actual counter (in bit positions, or would byte positions be
  enough?).
- a combination of the two (that would make our code extract the
  counters bits and only give those to the provided function, which
  then does the increment in any way it wishes).
There's no need for an IV for SSL/TLS encryption with AES CTR mode.
All that's needed is a counter, and a mechanism to prevent using
more than 2^38 or so bytes of keystream without changing the key.
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.  
Not quite.  You want to be sure to use block ciphers that are
differentially strong.  AES is particularly well-suited.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: AES counter mode

2003-06-26 Thread Michael Sierchio
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 as NIST-style.  There's Helger Lipmaa's
suggestion, and that's really it.  A 64-bit counter offers the
misleading sense that it is safe to use more than 2^32 blocks
of keystream.
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).
Can someone explain why the IPsec folks felt they needed to reimplement CTR
mode, especially in a way which appears to create more problems?
Yes.  SSL/TLS have the advantage of operating over TCP -- where
replay, delayed duplicates, out-of-order delivery, fragmentation,
etc. are all handled magically and elsewhere.  IPsec operates
via a connectionless medium with no delivery guarantees (IP).
Obviously we don't need nonces, just counters.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: AES counter mode

2003-06-26 Thread David Maurus
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(pCounter);
> else
> return Range_restart(pCounter);
The quoted code would restart counting when the counter overflows. That 
would open up a predictable opportunity for attack. I am still convinced 
that the default behaviour should be to report an error, and if this is 
not possible, increment over the bit-bound of the counter (increment the 
nonce), as this would cause the least damage.

The idea to have a function pointer for the increment function has the 
advantage that one could implement a counter function that would 
actually not count incrementally, but otherwise unique, as alluded to in 
the NIST recommendation (also page 19):
"This recommendation permits the use of any other incrementing function 
that generates n unique
strings of m bits in succession from the allowable initial strings. For 
example, if the initial string
of m bits is not the “zero” string, i.e., if it contains at least one 
‘1’ bit, then an incrementing
function can be constructed from a linear feedback shift register that 
is specialized to ensure a
sufficiently large period; see Ref. [5] for information about linear 
feedback shift registers."

But then, a mask based range check would not be sufficient, since you 
can't rely on any overflows.

In general, I'd prefer a more simple approach, like taking the counter 
bits as a parameter, and returning an int code ERR_LIB_NONE (?) if 
everything's OK, and an something like ERR_AES_CTR_OVERFLOW when the 
counter overflows...

- David



__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: AES counter mode

2003-06-26 Thread David Maurus
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 64 bits.
Where did you find that? Is it possible that you've got an older version?

In Nist's sp800-38a,
available at
http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
the corresponding paragraph concerning counter mode with nonces reads 
(page 19):

"A second approach to satisfying the uniqueness property across messages 
is to assign to each
message a unique string of b/2 bits (rounding up, if b is odd), in other 
words, a message nonce,
and to incorporate the message nonce into every counter block for the 
message. The leading b/2
bits (rounding up, if b is odd) of each counter block would be the 
message nonce, and the
standard incrementing function would be applied to the remaining m bits 
to provide an index to
the counter blocks for the message. Thus, if N is the message nonce for 
a given message, then
the jth counter block is given by Tj = N | [j]m, for j = 1…n. The number 
of blocks, n, in any
message must satisfy n < 2m. A procedure should be established to ensure 
the uniqueness of the
message nonces."

In the middle of this quotation you'll find the sentence: 'The leading 
b/2 bits (rounding up, if b is odd) of each counter block would be the 
message nonce, and the standard incrementing function would be applied 
to the remaining m bits to provide an index to the counter blocks for 
the message".

I think this is clear on the fact that e.g. with a 128 bit 'counter 
block' / IV, you'd use the leading 64 bits for the nonce (I'd interpret 
'leading' as the Most Significant Bits, if the bits would represent a 
number), while the remaining 64 bits of the 'counter block' / IV are the 
bits that are actually counting up, i.e. get incremented.

Unfortunately, the current API has no way to report "no more encryption
possible, you must rekey".
Given this limitation, two silent failure modes are possible: either wrap
and reuse ctr values, or don't wrap and use nonce values the user didn't
specify.
As I pointed out (I think), if you let the user provide an IV, let's say 
a 128 bit IV, and make clear in the documentation that the best way to 
use it would be to fill the highest 64 bit with a unique nonce, and 
clear the lowest 64 bits, as they will be used as a counter, there will 
be no problem. We could word the usage instructions even more general, 
saying that the lowest bits get used as counter, and that no more blocks 
should be encrypted with the same key and that counter, as the bits used 
as counter allow.

32bit counters can wrap in under a minute; IPsec clearly has a pressing
problem, but I'm not sure how to code to support both without giving up and
making the ctr-increment function a user parameter.
You're right. While as Lee Dilkie pointed out, the IPSec message format 
will not allow that this 32 bit counter will overflow, I'd like to 
refrain from my previous recommendation to 'follow the IPSec draft as 
close as possible' in this issue, since 32 bit are obiously not enough 
for SSL.

Per the NIST spec, the next nonce chosen will be the old nonce plus one, so
the user's choice will always be "unlucky".
Again, in the version of the NIST document I've linked to above, I can't 
find a statment that the nonce is to be incremented. I can only find the 
requirement that the nonce must be unique for the encryption key.

The easiest way to go about it would be to increment the user supplied
IV by 1 for each encrypted block, and leave it to the user of this
function to make sure that no overflow in the counter can occur. This
obligation to the programmer should be written somewhere in big letters
;-) (i.e. DON'T USE COUNTER MODE TO ENCRYPT MORE
THAN 2**32 [or 2**64, depending on the counter size] BLOCKS
WITH THE SAME KEY!). Higher level routines, i.e. the SSL BIO,
should avoid counter overflows automatically for the user by initiating a
rehandshake.
   

While this option is tempting, and the user does have access to the counter
at all times to check for impending overflow, experience shows that
programmers ignore such warnings more often than not.
Of course I'd be glad if we could check the counter and throw an 
exception when it overflows, but the interface for the low level crypto 
routines doesn't seem to accommodate that. All functions return a 
'void', e.g. nothing. I assume we cannot change that. (without breaking 
other parts).

Best Regards,
- David
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: AES counter mode

2003-06-26 Thread Götz Babin-Ebell
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 handling the IV, I can see three alternatives:
- have the application provide a function that manipulates the IV.
- have the application specify exactly which part of the IV is the
  actual counter (in bit positions, or would byte positions be
  enough?).
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;
A quick draft of my idea:

typedef struct _CounterData CounterData;
struct _CounterData
{
   Counter_Number nActual;  /* the actual counter value  */
   Counter_Number nStep;/* Step size added each step */
   Counter_Number nStepMask;/* Mask indikating when counter leaves
   range */
   int (*Count)(CounterData *pCounter); /* optional: handle a step,
   returns: < 0: error
   returns: > 0: OK. */
   int (*Range)(CounterData *pCounter); /* optional: is called if
   Count() returns out of range.
   returns: < 0: error
   returns: > 0: OK */
};
int Count(CounterData *pCounter)
{
   if (!pCounter)
  return -1;
   pCounter->nActual+= pCounter->nStep;
   return 1;
}
int Range_restart(CounterData *pCounter)
{
   if (!pCounter)
  return -1;
   pCounter->nActual &= ~pCounter->nStepMask;
   return 1;
}
int Range_terminate(CounterData *pCounter)
{
   return -1;
}
int Do_Counter(CounterData *pCounter)
{
   int nRet;
   if (!pCounter)
  return -1;
   if (pCounter->Count)
  nRet = pCounter->Count(pCounter);
   else
  nRet = Count(pCounter);
   if (nRet < 0)
  return nRet;
   if (pCounter->nActual & ~pCounter->nStepMask)
   {
  if (pCounter->Range)
 return pCounter->Range(pCounter);
  else
 return Range_restart(pCounter);
   }
   return nRet;
}
OK.
The Mask could be an upper bound...
Any comments ?

Bye

Goetz

--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0,  Fax: +49-(0)40 80 80 26 -126


smime.p7s
Description: S/MIME Cryptographic Signature


Re: AES counter mode

2003-06-26 Thread Richard Levitte - VMS Whacker
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 general
lee_dilkie> CTR mode that can accommodate all the versions (including
lee_dilkie> SRTP). I believe this is quite easy to do and does not
lee_dilkie> require any special handling. That way, I can use your
lee_dilkie> routines rather than my own, EVP-based, routines that
lee_dilkie> kinda hack EVP under the covers and are probably going to
lee_dilkie> be broken when I upgrade OSSL. :)

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.
- have the application specify exactly which part of the IV is the
  actual counter (in bit positions, or would byte positions be
  enough?).
- a combination of the two (that would make our code extract the
  counters bits and only give those to the provided function, which
  then does the increment in any way it wishes).

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 requested for AES, that's
where we currently have it.  Of course, if we had general mode
implementation instead of having them implemented with each algorithm,
things would be easier.  Unfortunately, we get bit by performance hits
if we do that (I think it was Steve who said he'd experimented with
things like that some time ago).

-- 
Richard Levitte   \ Tunnlandsvägen 3  \ [EMAIL PROTECTED]
[EMAIL PROTECTED]  \ S-168 36  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: as/400 port?

2003-06-26 Thread Ben Laurie
Brian C Morris wrote:

> 
> Hi -
> 
> We're entertaining the possibility of porting openssl to the AS/400
> (iSeries).
> 
> It seems from searching the archives this effort has been started before
> - but I assume not finished as I don't see reference to the platform in
> the code?
> 
> Is there still an effort under way that I could help with, or is there a
> better alternative for this platform?
> 
> Would a contribution of this nature be of interest?

Ports are always welcome.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


RE: AES counter mode

2003-06-26 Thread Lee Dilkie
Actually, SRTP was the first time I saw CTR mode and I believe it predates
NIST (i could be wy wrong there).

In SRTP, the counter is only 16 bits but that doesn't limit them to only
encrypting 64K blocks of data, it only limits them to 64K blocks *in one
rtp(udp) packet*. Obviously this isn't a limit as a udp packet cannot get
that big. The "nouce" part is modified for each packet (based on info in the
rtp header), so you can see there is no issue with counter overflow.

What I was trying (unsuccessfully) to make a point about. Please don't code
up your CTR mode to *just* do the NIST or Ipsec version of CTR mode. Please
code a general CTR mode that can accommodate all the versions (including
SRTP). I believe this is quite easy to do and does not require any special
handling. That way, I can use your routines rather than my own, EVP-based,
routines that kinda hack EVP under the covers and are probably going to be
broken when I upgrade OSSL. :)

(the other thing to remember is that CTR can be used with any block cipher,
it's not limited to AES)

regards,

-lee

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] 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
> 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 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 :-(
>
> Can someone explain why the IPsec folks felt they needed to
> reimplement CTR
> mode, especially in a way which appears to create more problems?
>
> S
>
> Stephen Sprunk "God does not play dice."  --Albert Einstein
> CCIE #3723 "God is an inveterate gambler, and He throws the
> K5SSSdice at every possible opportunity." --Stephen Hawking
>
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List   [EMAIL PROTECTED]
> Automated List Manager
> [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: AES counter mode

2003-06-26 Thread Stephen Sprunk
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 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 :-(

Can someone explain why the IPsec folks felt they needed to reimplement CTR
mode, especially in a way which appears to create more problems?

S

Stephen Sprunk "God does not play dice."  --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity." --Stephen Hawking

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: AES counter mode

2003-06-26 Thread Stephen Sprunk
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 successive block, and this is how I implemented the code.
> >
> 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 64 bits.

> In case of the AES-CTR IPSec draft, you get the IV by concatenating
> a msg number, a nonce, and the counter (at start initialized to 0). You
> can then safely incerement the 128 bit IV, *unless* you overflow the
> counter part (the lower 32 bits of the IV, according to the AES-CTR
> IPSec draft).

NIST's version does not have a message number, and the counter is 64 bits.

> >On the matter of overflowing the lower 64 bits, this is not specifically
> >addressed in the submission (I think they assumed nobody would exceed
2^64
> >blocks per stream, which is reasonable) and thus I think wrapping is the
> >correct failure.
> >
> I'm not sure what you mean with 'the correct failure', but the clean way
> to handle a counter overflow would be to fail / report an error, instead
> of continuing to encrypt.

Unfortunately, the current API has no way to report "no more encryption
possible, you must rekey".

Given this limitation, two silent failure modes are possible: either wrap
and reuse ctr values, or don't wrap and use nonce values the user didn't
specify.

The former is obviously bad, but IMHO the latter is equally bad.

> This discussion is academic for 64 bit counters, of course, as you
> probably won't see a 64 bit counter wrap very often. With a 32 bit
> counter however, the risk is a lot higher. Unfortunately, the current
> basic crypto functions offered by OpenSSL don't support returning an
> error condition, so 'failing' is not an option anyway.

64bit counters allow 256EB to be encrypted with a single key, and even at
today's maximum link speed of 10Gb/s, that's just under 69,731 years of
data.  Famous last words perhaps, but I think we can safely ignore that
problem.

32bit counters can wrap in under a minute; IPsec clearly has a pressing
problem, but I'm not sure how to code to support both without giving up and
making the ctr-increment function a user parameter.

> >To increment the nonce introduces a more insidious failure
> >mode where the user unintentionally reuses nonces.
> >
> It is debatable whether wrapping the counter would be less bad than
> incrementing the nonce part. A wrapping counter is more predictable for
> an attacker (as it would occur *always* when the communication exceeds
> 2**32 or 2 **64 blocks) than an unlucky nonce choice. In other words: If
> we let the counter wrap, the user is always affected when the counter
> overflows, and the weak spot is predictable. If we allow to increment
> the nonce instead of wrapping the counter, the user is only affected
> when the counter overflows, *and* he continues to reuse the same key but
> chooses a new nonce, *and* the choosen nonce value collides with the
> incremented nonce.

Per the NIST spec, the next nonce chosen will be the old nonce plus one, so
the user's choice will always be "unlucky".

> >Unfortunately, implementing this (as has been requested) would require
> >more significant changes to the API than I know how to make,as passing
> >parameters to a mode doesn't appear to be supported today.
>
> The easiest way to go about it would be to increment the user supplied
> IV by 1 for each encrypted block, and leave it to the user of this
> function to make sure that no overflow in the counter can occur. This
> obligation to the programmer should be written somewhere in big letters
> ;-) (i.e. DON'T USE COUNTER MODE TO ENCRYPT MORE
> THAN 2**32 [or 2**64, depending on the counter size] BLOCKS
> WITH THE SAME KEY!). Higher level routines, i.e. the SSL BIO,
> should avoid counter overflows automatically for the user by initiating a
> rehandshake.

While this option is tempting, and the user does have access to the counter
at all times to check for impending overflow, experience shows that
programmers ignore such warnings more often than not.

S

Stephen Sprunk "God does not play dice."  --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity." --Stephen Hawking

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: d2i and ASN1_CHOICE

2003-06-26 Thread Frank Balluffi

My bad. The following attempts to describe EXPLICIT tagging of elements of type CHOICE:

FOO DEFINITIONS EXPLICIT TAGS ::=

BEGIN

Foo ::= SEQUENCE
{
foo1 [0] EXPLICIT Goo,
foo2 [1] IMPLICIT Goo  -- Error: foo2 must be explicitly tagged.
}

Goo ::= CHOICE
{
integer1 [0] IMPLICIT INTEGER,
integer2 [1] EXPLICIT INTEGER
}

END

Frank



   
 
  "Dr. Stephen 
 
  Henson"   To:   [EMAIL PROTECTED]
   
  <[EMAIL PROTECTED]cc:
 
  > Subject:  Re: d2i and ASN1_CHOICE  
 
  Sent by: 
 
  owner-openssl-dev@   
 
  openssl.org  
 
   
 
   
 
  06/26/2003 09:43 
 
  AM   
 
  Please respond to
 
  openssl-dev  
 
   
 
   
 




On Thu, Jun 26, 2003, Frank Balluffi wrote:

>
> Fernando,
>
> I think all user-defined tags in a CHOICE (e.g., [0]) are EXPLICIT -- I could be 
> wrong and don't have time to check right now (it's been a while ...).
>
> So I think you want:
>
> ASN1_EXP(Seq1, value.field2,Sub_seq200, 0)
>

The default is EXPLICIT but the ASN1 module can change the default to
IMPLICIT.

IMPLIICT also must become EXPLICIT if its needed for disambiguiation, for
example if the underlying type is a CHOICE.

Steve.
--
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
Email: [EMAIL PROTECTED], PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]





--

This e-mail may contain confidential and/or privileged information. If you are not the 
intended recipient (or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail. Any unauthorized copying, disclosure or 
distribution of the material in this e-mail is strictly forbidden.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: d2i and ASN1_CHOICE

2003-06-26 Thread Dr. Stephen Henson
On Thu, Jun 26, 2003, Frank Balluffi wrote:

> 
> Fernando,
> 
> I think all user-defined tags in a CHOICE (e.g., [0]) are EXPLICIT -- I could be 
> wrong and don't have time to check right now (it's been a while ...).
> 
> So I think you want:
> 
> ASN1_EXP(Seq1, value.field2,Sub_seq200, 0)
> 

The default is EXPLICIT but the ASN1 module can change the default to
IMPLICIT.

IMPLIICT also must become EXPLICIT if its needed for disambiguiation, for
example if the underlying type is a CHOICE.

Steve.
--
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
Email: [EMAIL PROTECTED], PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: d2i and ASN1_CHOICE

2003-06-26 Thread Dr. Stephen Henson
On Thu, Jun 26, 2003, Fernando Moya wrote:

> Hi, I am having problems with CHOICE in the following ASN.1 sequence:
> 
> -
> DEFINITIONS IMPLICIT TAGS
> 
> Sub_seq200 ::= SEQUENCE
> {
>  sub_field1 Sub_seq100 OPTIONAL,
>  sub_field2 [0] Sub_seq400 OPTIONAL
>  }
> 
> Seq1 ::= CHOICE
>  {
>  field1 Sub_seq100,
>  field2 [0] Sub_seq200
>  }
> 
> -
> 
> Implemented by:
> 
> typedef struct Sub_seq200_st
> {
> Sub_seq100 *sub_field1;
> Sub_seq200 *sub_field2;
> }Sub_seq200;
> 
> typedef struct Seq1_st
> {
> int type;
> union {
> char *ptr;
> Sub_seq100 *field1;
> Sub_seq200 *field2;
> }value;
> }Seq1;
> 
> ASN1_SEQUENCE(Sub_seq200) = {
> ASN1_OPT(Sub_seq200,sub_field1, Sub_seq100),
> ASN1_IMP_OPT(Sub_seq200,sub_field2, Sub_seq400,0),
> } ASN1_SEQUENCE_END(Sub_seq200)
> 
> IMPLEMENT_ASN1_FUNCTIONS(Sub_seq200)
> 
> ASN1_CHOICE(Seq1) = {
> ASN1_SIMPLE(Seq1, value.field1,Sub_seq100),
> ASN1_IMP(Seq1, value.field2,Sub_seq200, 0)
> } ASN1_CHOICE_END(Seq1)
> 
> IMPLEMENT_ASN1_FUNCTIONS(Seq1)
> 
> Well, Seq1_new, Seq1_free and i2d_Seq1 functions work correctly and DER
> output is right, but when I call d2i_Seq1 with DER output from i2d_Seq1, it
> returns NULL. I think it could be an incorrect definition of
> ASN1_CHOICE(Seq1).
> 
> Does Anybody know what is wrong?
> 

See what error message you get with ERR_print_errors_fp(srderr);

Steve.
--
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
Email: [EMAIL PROTECTED], PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: d2i and ASN1_CHOICE

2003-06-26 Thread Frank Balluffi

Fernando,

I think all user-defined tags in a CHOICE (e.g., [0]) are EXPLICIT -- I could be wrong 
and don't have time to check right now (it's been a while ...).

So I think you want:

ASN1_EXP(Seq1, value.field2,Sub_seq200, 0)

Frank



   
 
  "Fernando Moya"  
 
  <[EMAIL PROTECTED]To:   <[EMAIL PROTECTED]>  
   
  > cc:
 
  Sent by:  Subject:  d2i and ASN1_CHOICE  
 
  owner-openssl-dev@   
 
  openssl.org  
 
   
 
   
 
  06/26/2003 04:55 
 
  AM   
 
  Please respond to
 
  openssl-dev  
 
   
 
   
 




Hi, I am having problems with CHOICE in the following ASN.1 sequence:

-
DEFINITIONS IMPLICIT TAGS

Sub_seq200 ::= SEQUENCE
{
 sub_field1 Sub_seq100 OPTIONAL,
 sub_field2 [0] Sub_seq400 OPTIONAL
 }

Seq1 ::= CHOICE
 {
 field1 Sub_seq100,
 field2 [0] Sub_seq200
 }

-

Implemented by:

typedef struct Sub_seq200_st
{
Sub_seq100 *sub_field1;
Sub_seq200 *sub_field2;
}Sub_seq200;

typedef struct Seq1_st
{
int type;
union {
char *ptr;
Sub_seq100 *field1;
Sub_seq200 *field2;
}value;
}Seq1;

ASN1_SEQUENCE(Sub_seq200) = {
ASN1_OPT(Sub_seq200,sub_field1, Sub_seq100),
ASN1_IMP_OPT(Sub_seq200,sub_field2, Sub_seq400,0),
} ASN1_SEQUENCE_END(Sub_seq200)

IMPLEMENT_ASN1_FUNCTIONS(Sub_seq200)

ASN1_CHOICE(Seq1) = {
ASN1_SIMPLE(Seq1, value.field1,Sub_seq100),
ASN1_IMP(Seq1, value.field2,Sub_seq200, 0)
} ASN1_CHOICE_END(Seq1)

IMPLEMENT_ASN1_FUNCTIONS(Seq1)

Well, Seq1_new, Seq1_free and i2d_Seq1 functions work correctly and DER
output is right, but when I call d2i_Seq1 with DER output from i2d_Seq1, it
returns NULL. I think it could be an incorrect definition of
ASN1_CHOICE(Seq1).

Does Anybody know what is wrong?

Thanks in advance.

Fernando Moya Bernal.
University of Malaga. Spain.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]





--

This e-mail may contain confidential and/or privileged information. If you are not the 
intended recipient (or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail. Any unauthorized copying, disclosure or 
distribution of the material in this e-mail is strictly forbidden.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: [PATCH] Building 0.9.7b with mingw special 20030504-1 (gcc3.2.3) on W2K fp3

2003-06-26 Thread Richard Levitte - VMS Whacker
In message <[EMAIL PROTECTED]> on Thu, 26 Jun 2003 13:38:45 +0200, "Michael Gerdau" 
<[EMAIL PROTECTED]> said:

mgd> Applying the following patch did solve the problem. I have not
mgd> checked wether this might happen with other Win32 environments too.
mgd> 
mgd> diff -ur openssl-0.9.7b-orig/util/pl/Mingw32.pl 
openssl-0.9.7b-work/util/pl/Mingw32.pl
mgd> --- openssl-0.9.7b-orig/util/pl/Mingw32.pl Sat Feb 22 01:25:37 2003
mgd> +++ openssl-0.9.7b-work/util/pl/Mingw32.pl Thu Jun 26 09:23:27 2003
mgd> @@ -85,7 +85,7 @@
mgd>($Name=$name) =~ tr/a-z/A-Z/;
mgd>  
mgd>$ret.="$target: \$(${Name}OBJ)\n";
mgd> -  $ret.="\t\$(RM) $target\n";
mgd> +  $ret.="\tif exist $target \$(RM) $target\n";
mgd>$ret.="\t\$(MKLIB) $target \$(${Name}OBJ)\n";
mgd>$ret.="\t\$(RANLIB) $target\n\n";
mgd>}

Fixed.

-- 
Richard Levitte   \ Tunnlandsvägen 3  \ [EMAIL PROTECTED]
[EMAIL PROTECTED]  \ S-168 36  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


[PATCH] Building 0.9.7b with mingw special 20030504-1 (gcc 3.2.3) on W2K fp3

2003-06-26 Thread Michael Gerdau
Hi !

When trying to build 0.9.7b fresh from the tarball by entering
ms\mingw32 on the cmd-prompt it stopped right before building
the static libraries when trying to remove the old ones.

My environment:
gcc.exe (GCC) 3.2.3 (mingw special 20030504-1)
Windows 2000 Professional fp3
openssl-0.9.7b

Applying the following patch did solve the problem. I have not
checked wether this might happen with other Win32 environments too.

diff -ur openssl-0.9.7b-orig/util/pl/Mingw32.pl openssl-0.9.7b-work/util/pl/Mingw32.pl
--- openssl-0.9.7b-orig/util/pl/Mingw32.pl  Sat Feb 22 01:25:37 2003
+++ openssl-0.9.7b-work/util/pl/Mingw32.pl  Thu Jun 26 09:23:27 2003
@@ -85,7 +85,7 @@
($Name=$name) =~ tr/a-z/A-Z/;
 
$ret.="$target: \$(${Name}OBJ)\n";
-   $ret.="\t\$(RM) $target\n";
+   $ret.="\tif exist $target \$(RM) $target\n";
$ret.="\t\$(MKLIB) $target \$(${Name}OBJ)\n";
$ret.="\t\$(RANLIB) $target\n\n";
}

Best,
Michael
--
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau   email: [EMAIL PROTECTED]
 Windows... just another pain in the glass ...
 GPG/PGP-keys available on request or at public keyserver


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


d2i and ASN1_CHOICE

2003-06-26 Thread Fernando Moya
Hi, I am having problems with CHOICE in the following ASN.1 sequence:

-
DEFINITIONS IMPLICIT TAGS

Sub_seq200 ::= SEQUENCE
{
 sub_field1 Sub_seq100 OPTIONAL,
 sub_field2 [0] Sub_seq400 OPTIONAL
 }

Seq1 ::= CHOICE
 {
 field1 Sub_seq100,
 field2 [0] Sub_seq200
 }

-

Implemented by:

typedef struct Sub_seq200_st
{
Sub_seq100 *sub_field1;
Sub_seq200 *sub_field2;
}Sub_seq200;

typedef struct Seq1_st
{
int type;
union {
char *ptr;
Sub_seq100 *field1;
Sub_seq200 *field2;
}value;
}Seq1;

ASN1_SEQUENCE(Sub_seq200) = {
ASN1_OPT(Sub_seq200,sub_field1, Sub_seq100),
ASN1_IMP_OPT(Sub_seq200,sub_field2, Sub_seq400,0),
} ASN1_SEQUENCE_END(Sub_seq200)

IMPLEMENT_ASN1_FUNCTIONS(Sub_seq200)

ASN1_CHOICE(Seq1) = {
ASN1_SIMPLE(Seq1, value.field1,Sub_seq100),
ASN1_IMP(Seq1, value.field2,Sub_seq200, 0)
} ASN1_CHOICE_END(Seq1)

IMPLEMENT_ASN1_FUNCTIONS(Seq1)

Well, Seq1_new, Seq1_free and i2d_Seq1 functions work correctly and DER
output is right, but when I call d2i_Seq1 with DER output from i2d_Seq1, it
returns NULL. I think it could be an incorrect definition of
ASN1_CHOICE(Seq1).

Does Anybody know what is wrong?

Thanks in advance.

Fernando Moya Bernal.
University of Malaga. Spain.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: HOWTO for pkcs11 patch?

2003-06-26 Thread Afchine Madjlessi
Hi,
I have written this patch to be used with a hardware Crypto PKCS#11
accelerator
which can store keys. It is used in my company in TrustWay SSL accelerator
and,
TrustWay Apache-SSL accelerator with the Bull PCI CC2000 HSM.
Our HSM doesn't require C_Login. I believe that call to C_Login is mandatory
on a smartcard.
In this case you must add it in the code. Gilad Finkelstein is working on it
and
I think that he will submit some changes for smartcard use.
About the handling of keys:
I have added a new entry (RSA_generate_key) in the RSA_METHOD to enable key
generation
in openssl. In the standard method (0.9.6-engine and 0.9.7) we are able to
load keys
(load_public_key and load_private_key) but it is supposed that the key is
generated
and stored outside openssl.
In the Bull TrustWay patch rsa_generate_key call PKCS#11 C_GenerateKeyPair,
to generate a key pair in the HSM. While the private key leave stored in the
HSM, the
public key is stored in a pem file on the disk. In standard mode you have
the private
key in this file. The modulus and exponent of the public key stored in the
pem file
permits to find the private key.
I join the shell script used to generate CA and server certificates and also
the patch
to apply to mod_ssl if you want to use apache-mod_ssl with openssl-pkcs#11
libcrypto.
Regards
Afchine
__
[EMAIL PROTECTED]
Bull TrustWay R&D
http://www.trustway.bull.com



- Original Message -
From: "Reinhard Moosauer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 26, 2003 8:48 AM
Subject: HOWTO for pkcs11 patch?


> Hello List,
>
> trustway's pkcs11-patch came with basically no info about it's usage.
> Especially the handling of stored keys on the smartcard is obscure.
> (openssl normally can only deal with files)
>
> req -newkey .. seems to work, but the key is not written to the card
>
> Please, please can anybody give some examples?
>
> TIA
>
> kind regards,
>
> Reinhard
>
>
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing List[EMAIL PROTECTED]
> Automated List Manager   [EMAIL PROTECTED]


CA-pkcs11.sh
Description: Binary data


tw-mod_ssl-2.8.14-1.3.27.patch
Description: Binary data