Re: HOWTO for pkcs11 patch?
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 RD 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
d2i and ASN1_CHOICE
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]
[PATCH] Building 0.9.7b with mingw special 20030504-1 (gcc 3.2.3) on W2K fp3
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]
Re: [PATCH] Building 0.9.7b with mingw special 20030504-1 (gcc3.2.3) on W2K fp3
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 http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: d2i and ASN1_CHOICE
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: d2i and ASN1_CHOICE
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
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
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: AES counter mode
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: 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]
RE: AES counter mode
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: as/400 port?
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
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 http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: AES counter mode
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
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 = 1n. 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
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 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
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
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
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 kudzuactual counter (in bit positions, or would byte positions be kudzuenough?). kudzu - a combination of the two (that would make our code extract the kudzucounters bits and only give those to the provided function, which kudzuthen 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 http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
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 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]
