Re: EVP_CipherInit() and similar API changes
Markus Friedl wrote: There could be more problems with other XXX_Init() or similar functions, so all semantic changes to functions from the 0.9.6 API should be reconsidered. All such changes could be a threat to existing applications and break them in subtle ways -- and this must be avoided. The aim of the API changes was to retain compatibility with existing code, there may be some places where it doesn't which need to be addressed. As to EVP_CipherInit(): I think EVP_CipherInit should not cause EVP_CipherInit_ex() to look for an engine, as this deviates from the 0.9.6 behaviour. Perhaps is better to pass 'engine==NO_ENGINE', instead of 'engine==NULL' to EVP_CipherInit_ex(). The aim of this was to allow the EVP_XXX functions to be able to use a replacement default implementation without needing to rewrite existing code. If no default implementation is loaded it should retain the 0.9.6 behaviour. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Gemplus: http://www.gemplus.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: EVP macros for AES
Thus spake Richard Levitte - VMS Whacker:
Note that this puts a requirement on the algorithm functions to follow
a certain name standard. The expected frunctions are, for a certain
{prefix} (AES in the AES case, I assume :-)):
{prefix}_ecb_encrypt
{prefix}_cbc_encrypt
{prefix}_ofb64_encrypt
{prefix}_cfb64_encrypt
I called the AES versions ofb128 and cfb128 due to the block size. I
expect this can be handled somehow by #defines. I could create 64-bit
feedback variants, but I don't think this is what people expect by
default.
All the arguments etc. are like the other cfb/ofb functions.
I don't think CTR is considered at all in the EVP layer. In other
words, you may implement it, but it will only be available as a direct
algorithm function, not as part of the EVP layer.
I suppose that's fine for now. It appears that CTR is going to be in
the NIST FIPS for AES modes, so it'd be nice to get it into EVP someday.
In any case, I can most certainly help you out, as I've already
fiddled with the first patches you sent.
I was figuring you would :)
S
--
Stephen Sprunk So long as they don't get violent, I want to
CCIE #3723 let everyone say what they wish, for I myself have
K5SSSalways said exactly what pleased me. --Albert Einstein
aes.modes.diff.bz2
Description: Binary data
Pentium Pro compiler optimizations
Has anyone been sucessfull using Pentium Pro compiler optimizations on UnixWare or OpenUNIX ? It builds but the md2test fails. All works fine without the -Kpentium_pro (-Kp6 on UW 2.1.x) flag. I see this problem on UnixWare 2.1.3 and OpenUNIX 8.0.0 My UnixWare 7.1.1 box runs a pentium so I can't test it there. I'm suspecting a compiler problem like on UnixWare 2.0x where it fails destest when -O is used. OpenSSL self-test report: OpenSSL version: 0.9.6c Last change: Fix BN_rand_range bug pointed out by Dominikus Scherkl... OS (uname): OpenUNIX ou8 5 8.0.0 i386 x86at Caldera UNIX_SVR5 OS (config): i386-unknown-OpenUNIX8.0.0 Target (default): OpenUNIX-8 Target: OpenUNIX-8-pentium_pro Compiler: UX:cc: INFO: Optimizing C Compilation System (CCS) 4.0 06/07/01 (OU8.0.0bl7) Failure! - [snip snip] ./md2test test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test 6 ok test 7 ok ./mdc2test 76009A1AEE4A5CC8A2176FCF7DC1 - generated 42E50CD224BACEBA760BDD2BD409281A - correct 9DA7D0372A30026AC189C0B5B065D767 - generated 2E4679B5ADD9CA7535D87AFEAB33BEE2 - correct *** Error code 1 (bu21) UX:make: ERROR: fatal error. *** Error code 1 (bu21) UX:make: ERROR: fatal error. - Thanks. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: EVP macros for AES
Stephen Sprunk wrote: Can someone help me implement the EVP macros for AES 128-bit CFB and OFB modes? It's too messy for me to figure out. I've got non-EVP versions written, but it appears the EVP macros do their own implementation of the various modes and only call the base ECB function. I've also got a trial implementation of CTR mode, but I don't see where that would fit into EVP or the ASN.1 stuff. The ASN.1 stuff you can largely ignore. Most of the existing CFB and OFB modes do and nothing really uses the ASN.1 stuff with those modes. The macros can also be ignored and you can populate the EVP_CIPHER structure manually if you wish. The reason for the macros was that when the EVP layer was being revised it was an absolute nightmare to change anything. IIRC at one point I had to add an additional field to the EVP_CIPHER structure. I then spent the next couple of hours modifying lots of almost identical EVP_CIPHER definitions spread over zillions of little files. So I rewrote the files to use macros so that any future changes could largely be handled by just changing the macros and the odd exception manually. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Gemplus: http://www.gemplus.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: EVP_CipherInit() and similar API changes
Markus Friedl wrote:
I think this change is needed if you want EVP_CipherInit() to have a
similar semantic as in OpenSSL 0.9.6.
Index: evp/evp_enc.c
===
RCS file: /cvs/openssl/crypto/evp/evp_enc.c,v
retrieving revision 1.28
diff -u -r1.28 evp_enc.c
--- evp/evp_enc.c 17 Oct 2001 00:36:34 - 1.28
+++ evp/evp_enc.c 13 Feb 2002 10:28:05 -
@@ -77,7 +77,8 @@
int EVP_CipherInit(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *cipher,
const unsigned char *key, const unsigned char *iv, int enc)
{
- EVP_CIPHER_CTX_init(ctx);
+ if (cipher)
+ EVP_CIPHER_CTX_init(ctx);
return EVP_CipherInit_ex(ctx,cipher,NULL,key,iv,enc);
}
Otherwise you will break code like:
EVP_CIPHER_CTX c;
EVP_CIPHER_CTX_init(c);
EVP_CipherInit(c, cipher, NULL, iv, enc);
/* adjust keylength */
EVP_CIPHER_CTX_set_key_length(c, keylen)
EVP_CipherInit(c, NULL, key, NULL, -1);
Oops, forgot to comment on that. Yes its definitely a bug, good catch!
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Problem with Make
Hi I am trying to install openssl-0.9.6b on Sun Solaris 8. After successfully running the config, I am getting error when I run make I am attaching the output of make and make report. Waiting eagerly for your response Thanking in advance Regards Rakesh makereport.out Description: Binary data make.out Description: Binary data
Re: 0.9.7 approaching
From: Richard Levitte - VMS Whacker [EMAIL PROTECTED]
levitte 3) In the snapshot directory, the 0.9.7-dev snapshots are now called
levitteopenssl-0.9.6-stable-SNAP-{MMDD}.tar.gz, where {MMDD} is
levittereplaced with the datestamp of the snapshot.
That was supposed to say openssl-0.9.7-stable-SNAP-{MMDD}.tar.gz
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-733-72 88 11
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, GemPlus: http://www.gemplus.com/
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]
0.9.7 make test needs work
The make test in 0.9.7 needs a little work.
It requires a previous SSL installation.
...
Tests completed happily
./evp_test evptests.txt
Auto configuration failed
3562:error:02001002:system library:fopen:No such file or
directory:bss_file.c:104:fopen('/usr/local/ssl/openssl.cnf','rb')
3562:error:2006D080:BIO routines:BIO_new_file:no such file:bss_file.c:107:
3562:error:0E064002:configuration file routines:CONF_load:system lib:conf_def.c:198:
make[2]: *** [test_evp] Error 1
make[2]: Leaving directory `/usr/local/src/libs/openssl-SNAP-20020212/test'
...
It this is a first time install you can't expect it to be able to
open /usr/local/ssl/openssl.cnf
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
AES and difference between engine and not
-BEGIN PGP SIGNED MESSAGE- I would have thought that this would be a FAQ. It is not. What is the engine? I was however, specifically trying to determine if anyone has started any work on having an AES integrated into openssl. http://www.mail-archive.com/openssl-dev@openssl.org/msg10670.html suggests that it will be in the 0.9.7 release? (I am asking with my FreeSWAN and tcpdump hat on. We need to have AES support in print-esp.c before we bother coding it for FreeSWAN) ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic(Just another NetBSD/notebook using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPGrcj4qHRg3pndX9AQExiQQAiGYocFsrZCVKxBDO1Du/qlVwb9YHiX3B uSAskA7SMQtQ9v/8K2atLeDCP5i95QwLFFb8b3elHUKx8h+xIk0B9/949TCi/YTq o7GQisSxBw/s+b/x6WxFi7nTCNO47xP70BY+v0yUGWN9fe6Pven6xVOvxsXKlgVu vruKfDgmK1c= =VRRZ -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] openssl for VxWorks
Since you're in the USA (or at least w7optics.com is), you have to resend that patch with a cc: to [EMAIL PROTECTED] (see www.crypto.com for explanations), or otherwise we can't accept it. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ 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: [PATCH]: Configure OpenSSL for Cygwin with threading and shared library support
On Tue, Jan 22, 2002 at 05:35:38PM +0100, Corinna Vinschen wrote: On Tue, Jan 22, 2002 at 04:48:58PM +0100, Richard Levitte - VMS Whacker wrote: From: Corinna Vinschen [EMAIL PROTECTED] vinschen I don't want to be pushy but I'd like to know if I have to do vinschen something to get approval for that patch. I'm pretty sure I put it in my queue of patches to look through. It'll probably get in as soon as I (or someone else) have done a sanity check, unless it already has and I haven't noticed. Thanks for the feedback, Corinna Hi, is this patch still in the loop? Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: EVP macros for AES
From: Stephen Sprunk [EMAIL PROTECTED]
stephen Can someone help me implement the EVP macros for AES 128-bit CFB and
stephen OFB modes? It's too messy for me to figure out.
stephen
stephen I've got non-EVP versions written, but it appears the EVP macros do
stephen their own implementation of the various modes and only call the base
stephen ECB function.
Nope, they don't do their own implementation, all they do is write EVP
wrappers that call the different functions of the algorithm itself.
Note that this puts a requirement on the algorithm functions to follow
a certain name standard. The expected frunctions are, for a certain
{prefix} (AES in the AES case, I assume :-)):
{prefix}_ecb_encrypt
{prefix}_cbc_encrypt
{prefix}_ofb64_encrypt
{prefix}_cfb64_encrypt
Furthermore, there are a few semantic things. All of those functions
have to use the exact same arguments for all algorithms, except for
the key schedule argument. Also, {prefix}_ecb_encrypt is expected to
encrypt only one block, while the others are expected to encrypt the
whole message that is sent to them.
stephen I've also got a trial implementation of CTR mode, but I don't
stephen see where that would fit into EVP or the ASN.1 stuff.
I don't think CTR is considered at all in the EVP layer. In other
words, you may implement it, but it will only be available as a direct
algorithm function, not as part of the EVP layer.
In any case, I can most certainly help you out, as I've already
fiddled with the first patches you sent.
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-733-72 88 11
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, GemPlus: http://www.gemplus.com/
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: [PATCH]: Configure OpenSSL for Cygwin with threading andshared library support
From: Corinna Vinschen [EMAIL PROTECTED] vinschen is this patch still in the loop? Thanks for the reminder! I had never put it in my patch queue while I was considering your answers to my questions, and then other things got heaped on me. I've now reched the patch and really put it my queue, and I can say with almost certainty that it will get in with very few changes. One question remains before I go ahead: is it possible to have config check the version of Cygwin and decide for another configuration target if it's too old to provide thread safety. Since people with older Cygwin installation may take the OpenSSL source and build it there, it's of utmost importance that we get that part right, or we'll just get a deluge of needless support requests from worried people. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ 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: [PATCH]: Configure OpenSSL for Cygwin with threading and shared library support
On Wed, Feb 13, 2002 at 11:47:23AM +0100, Richard Levitte - VMS Whacker wrote: One question remains before I go ahead: is it possible to have config check the version of Cygwin and decide for another configuration target if it's too old to provide thread safety. Since people with older Cygwin installation may take the OpenSSL source and build it there, it's of utmost importance that we get that part right, or we'll just get a deluge of needless support requests from worried people. The output of uname -r (which is stored in $RELEASE) could be used for that. The following check could help: case $RELEASE in [bB]*|1.0|1.[12].*) options=$options no-threads no-asm no-shared ;; esac This switches back to the old behaviour in case of the old B15-B20 versions and all versions from 1.0 up to 1.2.x while the new state is used for 1.3.x upwards. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH]: Configure OpenSSL for Cygwin with threading andshared library support
From: Corinna Vinschen [EMAIL PROTECTED] vinschen case $RELEASE in vinschen [bB]*|1.0|1.[12].*) vinschen options=$options no-threads no-asm no-shared ;; vinschen esac vinschen vinschen This switches back to the old behaviour in case of the old vinschen B15-B20 versions and all versions from 1.0 up to 1.2.x while vinschen the new state is used for 1.3.x upwards. Thanks for the info. OK, your patch is applied and slightly modified, and will be commited in a moment. Please download the next snapshot (both of 0.9.6x and 0.9.7-dev) and try them out. The next snapshot will be built around 0100 CET tomorrow morning. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ 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: [ietf-tls] Re: an attack against SSH2 protocol
On Wed, Feb 13, 2002 at 03:57:59PM +0200, Hugo Krawczyk wrote: [...] Thus, future revisions of TLS should also take this into account. That is, either transmit a fresh (unpredictable) IV with each msg, or implcitly compute this IV in an *unpredictable* way, for example by applying a prf to the msg counter. What about using the MAC as a prefix instead of postfix to the plaintext? If the MAC is secure, it certainly will be unpredictable, so the encrypted MAC (which is the effective IV for the actual data) will be unpredictable as well. Another problem with CBC as used in SSL/TLS was pointed out by Serge Vaudenay, see URL:http://www.openssl.org/~bodo/tls-cbc.txt. That one can easily be avoided by implementations. To avoid the new attack without changing the protocol definition, implementations would have to send an empty fragment before application data to ensure IV randomization. This is a nice attack (do you know of a publicly available paper on this that I can cite?), and indeed easier to fix than the others. It's now a technical report: Serge Vaudenay CBC Padding: Security Flaws in SSL, IPSEC, WTLS, ... DSC Technical Report 200150, EPFL, 2001. URL:http://lasecwww.epfl.ch/query.msql?ref=Vau01 The analytical model in my paper (for the case of authenticate-then-encrypt with CBC) makes the assumption that decryption and mac verification are performed as an atomic operation with a single ciphertext invalidity bit learned by the attacker regardless of the reason for failure. This points out to yet another advantage of the encrypt-then-mac approach, namely, there you first check the MAC and if not valid you do NOT decrypt (in particular, you provide no info to the other side or the atacker about the result of decryption). No need for assumptions on the atomicity of combined operations. I agree, this is a nice property. I wonder if any one cares in ssl/tls community about all these basic crypto-security design issues; I certainly do -- any plans for future protocol versions? so I was going to ask this myself. PS: since Wei Dai mentioned the case of SSH in this context, the bad news there is that even using CBC and fixing the problem of predictable IV leaves the protocol open to the attacks on authenticate-and-mac showed in my paper (e.g. the attack in appendix C) Previously I had only mentioned the CRYPTO 2001 version of the paper (which does not have an Appendix C). Here's a pointer to the full paper: Hugo Krawczyk The order of encryption and authentication for protecting communications (Or: how secure is SSL?) Cryptology ePrint Archive: Report 2001/045 URL:http://eprint.iacr.org/2001/045/ -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH]: Configure OpenSSL for Cygwin with threading and shared library support
On Wed, Feb 13, 2002 at 02:54:46PM +0100, Richard Levitte - VMS Whacker wrote: From: Corinna Vinschen [EMAIL PROTECTED] vinschen case $RELEASE in vinschen [bB]*|1.0|1.[12].*) vinschen options=$options no-threads no-asm no-shared ;; vinschen esac vinschen vinschen This switches back to the old behaviour in case of the old vinschen B15-B20 versions and all versions from 1.0 up to 1.2.x while vinschen the new state is used for 1.3.x upwards. Thanks for the info. OK, your patch is applied and slightly modified, and will be commited in a moment. Please download the next snapshot (both of 0.9.6x and 0.9.7-dev) and try them out. The next snapshot will be built around 0100 CET tomorrow morning. Thanks! I'll test it. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
0.9.7 approaching
The OpenSSL 0.9.7 release cycle has started.
Be at ease, we're still a bit away from making betas, there are a
couple of rather serious bugs to fix. However, this means that a few
changes have been made:
1) In the CVS repository, there's now a branch tagged with the name
OpenSSL_0_9_7-stable.
2) The main trunk is now 0.9.8-dev.
3) In the snapshot directory, the 0.9.7-dev snapshots are now called
openssl-0.9.6-stable-SNAP-{MMDD}.tar.gz, where {MMDD} is
replaced with the datestamp of the snapshot.
4) openssl-SNAP-{MMDD}.tar.gz are now snapshots of 0.9.8-dev.
Please test the 0.9.7-dev snapshots and report any problems that you
found, even if they have been reported before (it's a good reminder
for us), or even better, send us patches!
The 0.9.7 branch should have very few (preferably no) features added.
If you want a feature added, you'll have to wait for the release of
0.9.8 or release a patch kit on your own.
Happy testing, happy hacking!
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-733-72 88 11
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, GemPlus: http://www.gemplus.com/
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]
EVP_CipherInit() and similar API changes
I think this change is needed if you want EVP_CipherInit() to have a
similar semantic as in OpenSSL 0.9.6.
Index: evp/evp_enc.c
===
RCS file: /cvs/openssl/crypto/evp/evp_enc.c,v
retrieving revision 1.28
diff -u -r1.28 evp_enc.c
--- evp/evp_enc.c 17 Oct 2001 00:36:34 - 1.28
+++ evp/evp_enc.c 13 Feb 2002 10:28:05 -
@@ -77,7 +77,8 @@
int EVP_CipherInit(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *cipher,
const unsigned char *key, const unsigned char *iv, int enc)
{
- EVP_CIPHER_CTX_init(ctx);
+ if (cipher)
+ EVP_CIPHER_CTX_init(ctx);
return EVP_CipherInit_ex(ctx,cipher,NULL,key,iv,enc);
}
Otherwise you will break code like:
EVP_CIPHER_CTX c;
EVP_CIPHER_CTX_init(c);
EVP_CipherInit(c, cipher, NULL, iv, enc);
/* adjust keylength */
EVP_CIPHER_CTX_set_key_length(c, keylen)
EVP_CipherInit(c, NULL, key, NULL, -1);
Generally I think the way 0.9.7 introduces subtle changes into the
existing API is dangerous. Considering how many people deploy and
depend on your library, you should rather opt for adding a completely
new API than fixing bugs of the existing API by introducing subtle
semantic changes.
There could be more problems with other XXX_Init() or similar
functions, so all semantic changes to functions from the 0.9.6 API
should be reconsidered. All such changes could be a threat to existing
applications and break them in subtle ways -- and this must be
avoided.
Even if you consider your API unstable and subject to change -- your
users don't. You cannot undo the success of your library :)
As to EVP_CipherInit(): I think EVP_CipherInit should not cause
EVP_CipherInit_ex() to look for an engine, as this deviates from the
0.9.6 behaviour. Perhaps is better to pass 'engine==NO_ENGINE',
instead of 'engine==NULL' to EVP_CipherInit_ex().
-m
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [ietf-tls] Re: an attack against SSH2 protocol
On Fri, 8 Feb 2002, Bodo Moeller wrote: In TLS, the IV for subsequent records is the last ciphertext block from the previous record [RFC 2246], and plaintext blocks usually consist of raw application data followed by a MAC, so the attack applies. (Having the MAC at the *beginning* of each packet would avoid the attack.) In his CRYPTO 2001 paper The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?), Hugo Krawczyk supposedly shows that SSL/TLS with CBC encryption is secure -- but he assumes a random IV for each encrypted block, which is not how the actual SSL protocol works. Bodo's observation is correct. My paper essentially assumes a random IV per message. Without it (i.e. with the specification of using the last ctext block from msg i as the IV of msg i+1) CBC mode is NOT even secure against chosen plaintext attacks! In this case even MACing the ciphertext does not help. Thus, future revisions of TLS should also take this into account. That is, either transmit a fresh (unpredictable) IV with each msg, or implcitly compute this IV in an *unpredictable* way, for example by applying a prf to the msg counter. Another problem with CBC as used in SSL/TLS was pointed out by Serge Vaudenay, see URL:http://www.openssl.org/~bodo/tls-cbc.txt. That one can easily be avoided by implementations. To avoid the new attack without changing the protocol definition, implementations would have to send an empty fragment before application data to ensure IV randomization. This is a nice attack (do you know of a publicly available paper on this that I can cite?), and indeed easier to fix than the others. The analytical model in my paper (for the case of authenticate-then-encrypt with CBC) makes the assumption that decryption and mac verification are performed as an atomic operation with a single ciphertext invalidity bit learned by the attacker regardless of the reason for failure. This points out to yet another advantage of the encrypt-then-mac approach, namely, there you first check the MAC and if not valid you do NOT decrypt (in particular, you provide no info to the other side or the atacker about the result of decryption). No need for assumptions on the atomicity of combined operations. I wonder if any one cares in ssl/tls community about all these basic crypto-security design issues; any plans for future protocol versions? Hugo PS: since Wei Dai mentioned the case of SSH in this context, the bad news there is that even using CBC and fixing the problem of predictable IV leaves the protocol open to the attacks on authenticate-and-mac showed in my paper (e.g. the attack in appendix C) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[PATCH] openssl for VxWorks
Hi,
I have a patch to allow openssl to be built for a VxWorks
target.
Specifically a PowerPC 405 target, but changing targets should
be
a matter of adding a line in the Configure file.
I am primarily concerned with the libcrypt functionality and
have not
ported all of the apps code (although it does build).
The config script doesn't seem to pick up cross compiling
environments,
so you have to start with ./Configure vxworks-ppc405 instead.
A pretty simple port job, beats paying $30K US for a commercial
port of
the same code...
bill
--
Bill Pitts
Senior Software Engineer
Wave7 Optics
[EMAIL PROTECTED]
patchfile
--
diff -r -u -x Make* ./openssl-0.9.6c/Configure
./openssl-0.9.6c-vxworks/Configure
--- ./openssl-0.9.6c/Configure Thu Dec 6 08:11:39 2001
+++ ./openssl-0.9.6c-vxworks/Configure Tue Feb 5 14:00:07 2002
@@ -480,6 +480,9 @@
# Sony NEWS-OS 4.x
newsos4-gcc,gcc:-O -DB_ENDIAN -DNEWS4::(unknown):-lmld
-liberty:BN_LLONG RC4_CHAR RC4_CHUNK DES_PTR DES_RISC1 DES_UNROLL
BF_PTR,
+# VxWorks for various targets
+vxworks-ppc405,ccppc:-g -msoft-float -mlongcall -DVXWORKS
-DCPU=PPC405 -I\$(WIND_BASE)/target/h:::-r:,
+
);
my @WinTargets=qw(VC-NT VC-WIN32 VC-WIN16 VC-W31-16 VC-W31-32 VC-MSDOS
BC-32
diff -r -u -x Make* ./openssl-0.9.6c/apps/ca.c
./openssl-0.9.6c-vxworks/apps/ca.c
--- ./openssl-0.9.6c/apps/ca.c Tue May 22 08:48:14 2001
+++ ./openssl-0.9.6c-vxworks/apps/ca.c Tue Feb 5 10:44:04 2002
@@ -82,7 +82,7 @@
#else
# include unixlib.h
#endif
-# else
+# elif !defined(VXWORKS)
#include sys/file.h
# endif
#endif
diff -r -u -x Make* ./openssl-0.9.6c/apps/s_server.c
./openssl-0.9.6c-vxworks/apps/s_server.c
--- ./openssl-0.9.6c/apps/s_server.cSat Mar 31 02:47:32 2001
+++ ./openssl-0.9.6c-vxworks/apps/s_server.cTue Feb 5 13:08:18 2002
@@ -62,6 +62,7 @@
#include string.h
#include sys/types.h
#include sys/stat.h
+
#ifdef NO_STDIO
#define APPS_WIN16
#endif
@@ -77,6 +78,7 @@
#include openssl/lhash.h
#include openssl/bn.h
+
#define USE_SOCKETS
#include apps.h
#include openssl/err.h
diff -r -u -x Make* ./openssl-0.9.6c/apps/s_time.c
./openssl-0.9.6c-vxworks/apps/s_time.c
--- ./openssl-0.9.6c/apps/s_time.c Fri Feb 11 04:46:55 2000
+++ ./openssl-0.9.6c-vxworks/apps/s_time.c Tue Feb 5 13:56:50 2002
@@ -82,7 +82,7 @@
#include wintext.h
#endif
-#if !defined(MSDOS) (!defined(VMS) || defined(__DECC))
+#if !defined(MSDOS) !defined(VXWORKS) (!defined(VMS) ||
defined(__DECC))
#define TIMES
#endif
@@ -102,7 +102,7 @@
#undef TIMES
#endif
-#ifndef TIMES
+#if !defined(TIMES) !defined(VXWORKS)
#include sys/timeb.h
#endif
@@ -139,6 +139,14 @@
#undef BUFSIZZ
#define BUFSIZZ 1024*10
+#ifdef min
+#undef min
+#endif
+
+#ifdef max
+#undef max
+#endif
+
#define min(a,b) (((a) (b)) ? (a) : (b))
#define max(a,b) (((a) (b)) ? (a) : (b))
@@ -368,6 +376,22 @@
ret=((double)(tend.tms_utime-tstart.tms_utime))/HZ;
return((ret == 0.0)?1e-6:ret);
}
+#elif defined(VXWORKS)
+{
+ static unsigned long tick_start, tick_end;
+
+ if( s == START )
+ {
+tick_start = tickGet();
+return 0;
+ }
+ else
+ {
+tick_end = tickGet();
+ret = (double)(tick_end - tick_start) /
(double)sysClkRateGet();
+return((ret == 0.0)?1e-6:ret);
+ }
+}
#else /* !times() */
static struct timeb tstart,tend;
long i;
diff -r -u -x Make* ./openssl-0.9.6c/apps/speed.c
./openssl-0.9.6c-vxworks/apps/speed.c
--- ./openssl-0.9.6c/apps/speed.c Wed Apr 11 06:06:44 2001
+++ ./openssl-0.9.6c-vxworks/apps/speed.c Tue Feb 5 13:51:54 2002
@@ -84,10 +84,10 @@
#if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
# define USE_TOD
-#elif !defined(MSDOS) (!defined(VMS) || defined(__DECC))
+#elif !defined(MSDOS) !defined(VXWORKS) (!defined(VMS) ||
defined(__DECC))
# define TIMES
#endif
-#if !defined(_UNICOS) !defined(__OpenBSD__) !defined(sgi)
!defined(__FreeBSD__) !(defined(__bsdi) || defined(__bsdi__))
!defined(_AIX) !defined(MPE) !defined(__NetBSD__)
+#if !defined(_UNICOS) !defined(__OpenBSD__) !defined(sgi)
!defined(__FreeBSD__) !(defined(__bsdi) || defined(__bsdi__))
!defined(_AIX) !defined(MPE) !defined(__NetBSD__)
!defined(VXWORKS)
# define TIMEB
#endif
@@ -115,7 +115,7 @@
#include sys/timeb.h
#endif
-#if !defined(TIMES) !defined(TIMEB) !defined(USE_TOD)
+#if !defined(TIMES) !defined(TIMEB) !defined(USE_TOD)
!defined(VXWORKS)
#error It seems neither struct tms nor struct timeb is supported in
this platform!
#endif
@@ -303,6 +303,25 @@
}
}
# endif
+
+# ifdef VXWORKS
+{
+
