Re: OpenSSL breaks with gcc 4.2
Thus spake Peter Waltenberg x is still just a pointer to data - so it's the same length in any case, all pointers to lvalues are the same length in C. The only issue there is whether it's aligned correctly - that's the programmers problem. It's not the only problem. Mixing something like char *(*d2i)(), and char ** IS problematic, since those aren't guaranteed to be the same length but as far as I can remember OpenSSL doesn't do that. ret=d2i(x,p,len); d2i is a function (prototype is unknown) but I've been told x is a pointer, p is a pointer, len is long. There's nothing indeterminate about the size of any of those. Incorrect. When the compiler encounters this statement, if there's no prototype for d2i() in scope, it is _required_ to act as if the prototype were: int d2i(int, int, int); Since you're passing two pointers and a long, this is simply invalid. It may work on some platforms, but it's undefined behavior and a compiler is free to do whatever it wants (including insert code to crash the program). C isn't a strongly typed language - there's no language requirement for an accurate function prototype or that the types of the arguments be correct - only that the size of them is correct. C89 had already deprecated non-prototyped functions. In C99, they're prohibited, so there is a requirement today. C is not the same language as C++, this instance should work with a C compiler - whether or not the compiler is passing the arguments via the stack or in registers. Again, not correct. There are implementations that pass ints, longs, and pointers all in different registers. Some platforms have specific registers for pointers, just like many have specific registers for floats/doubles. Others will have the top half of a long corrupted if sizeof(long)sizeof(int), which is common on many 64-bit machines. 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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] make AES-cfb128-encrypt faster by uglifying it
Thus spake Alex Dubov [EMAIL PROTECTED] Ok. How about now? I'm curious if there's a significant performance difference between using u32 and u64; the former should be portable to all supported platforms, and may make the latter unnecessary. Plus, if we're going to go that route, we should consider that some platforms have 128-bit XOR support in hardware; is it worth implementing that too? How much of this should be extended to other ciphers? Should xorN() and moveN() be part of the bignum code for reuse in other modules? IIRC, I copied the CFB code from another module (DES? IDEA? I forget) with only slight changes; I didn't grok enough of it at the time to worry about performance, just maintaining correctness. S Stephen SprunkStupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them. --Aaron Sorkin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] make AES-cfb128-encrypt faster by uglifying it
Thus spake Andy Polyakov [EMAIL PROTECTED] Ok. How about now? Subject to SIGBUS on most platforms. It's easy to carry away and score on x86 and render support for other platforms void, isn't it? I mean do mind unaligned access! Ah, that may have been why I didn't fix that code to use u32. More likely, it was a happy accident that I inherited the portability of the code I copied. I certainly introduced a few logic bugs of my own (which were quickly fixed by others)... I'm curious if there's a significant performance difference between using u32 and u64; the former should be portable to all supported platforms, and may make the latter unnecessary. I'd recommend [or even insist] on for (i=0;i16/sizeof(long);i++) loops and let compiler unroll them. 4x4-byte chunks on 32-bit platforms and 2x8-byte chunks - on 64-bit ones without a single shred of #if that-or-that spaghetti and no unnecessary dependency on totally unrelated bn.h. And once again, unaligned input/output is to be treated byte by byte. My experience is that, for blocks as short as we're discussing here, the tests for unaligned blocks usually defeat the benefit you get in the aligned case. Functions like memcpy() generally require a minimum size before they try any such trickery due to the cost of the test, and 16 bytes is probably on the edge for most platforms. If you're using a platform that will transparently handle unaligned access (either in hardware or software), it's worth it, but IMHO not on code that has to work on platforms that don't. Plus, if we're going to go that route, we should consider that some platforms have 128-bit XOR support in hardware; is it worth implementing that too? Is it really that widely used/important mode? To justify that much extra complexity for little gain? I hacked up a version of the AES code a while back that used SSE registers to pass the blocks around, do bitwise operations, etc. It was faster than the current version, but (IMHO) not enough to justify adding so much unportable hackery to the project. If one desperately needs speed, the existing approach is to use platform-specific asm, and that seems sufficient. How much of this should be extended to other ciphers? Should xorN() and moveN() be part of the bignum code for reuse in other modules? I'd be opposed to this. If performance gets that important, function call will hardly beat inline code anyway. Even if function is say 128-bit SSE2 and inline is just 4x32-bit. A. When I find such things useful, I tend to put them in a module's headers as a static inline function; that gets the speed of a macro with the semantics and safety of a real function. Unfortunately, that approach probably won't work on all of the platforms OpenSSL supports due to all the ancient compilers floating around. S Stephen SprunkStupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them. --Aaron Sorkin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: AES ( Advanced Encryption Standard)
Thus spake José Luis Navarro Adam [EMAIL PROTECTED] As I know, AES was the encryptation algorithm selected by AES due to best performance with dedicated hardware... You mean Rijndael was the algorithm selected by NIST to be AES due to the best overall performance across a variety of implementations, including but not limited to dedicated hardware. Actually, openssl recommends Blowfish (other AES finalist) because its performance by software encryptation (as Linux is) is much better... To my knowledge, the OpenSSL Project doesn't recommend any particular cipher. Blowfish was not an AES candidate because it did not meet several of the requirements. Twofish was an adaptation that was considered, but its performance was worse and was very difficult to understand (and therefore to cryptoanalyze). While Bruce Schneier was unhappy his Twofish algorithm wasn't selected, he has publicly stated that Rijndael is a good choice. Anyway, I have read taht it will do soon with AES. AES code has been in OpenSSL snapshots for quite a while. Please, have a look at http://www.sans.org/rr/papers/20/1459.pdf This article from charlie Hosner of SANS Institute talks about this... That article is about OpenVPN, not OpenSSL, which is only mentioned twice in passing. And, for that matter, one of those mentions does show that OpenSSL has AES implemented already. S Stephen SprunkStupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them. --Aaron Sorkin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: AES ( Advanced Encryption Standard)
Thus spake CHIN, LEY-HUA (Ginger) [EMAIL PROTECTED]: Does OpenSSL support AES? If it does, where can I find the document for AES API? I checked on www.openssl.org, no luck! If it doesn't, then will it support in the near future? AES is in the current snapshots, but it will not be in a release until 0.9.8 comes out. Presumably documentation will follow. In the meantime, if you want to call the AES functions directly, look at the crypto/aes/aes.h header file. If you use the EVP interface, just specify which mode/keysize of AES you want (there are now 18 combinations) and use the EVP interface like you would with any other cipher. S Stephen SprunkStupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them. --Aaron Sorkin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Porting OpenSSL
Thus spake Gary Walters [EMAIL PROTECTED] I have been working on porting OpenSSL to the THEOS Operating System. The C compiler is ANSI C compliant and mostly ISO C99 compliant. However, it is not as feature rich as GCC. . My main problem is with the function pointer callbacks that accept parameters. I'm finding that I have to modify the source a lot in order to get it to compile. Pointers to functions that take arguments are allowed by C89/C90; perhaps your compiler isn't as compliant as the authors think? S Stephen Sprunk Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do. K5SSS --Isaac Asimov __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: AES_CBC decryption
Thus spake mohanlal jangir [EMAIL PROTECTED] I was looking into the AES CBC code available at http://openbsd.secsup.org/src/lib/libssl/src/crypto/aes/ For testing this, I wrote small code (attached in mail). The Encryption seems OK but Decryption is failing. I think, I am doing some mistake. Could you please look into the code and give me some hints about decryption. Minor bug: the AES CBC function doesn't correctly handle in==out. Please retry with in!=out. 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 Thierry Boivin [EMAIL PROTECTED] I agree with this approach which leaves the crypto library very open and not to complex to manipulate, whatever the upper program to develop is. Generalized approach : as differencies for the various applications are the way to build the IV, ie: nonce part /upper counter part / lower counter part /whatever part, and, in my opinion, not the way to increment such a global IV from block to block, I would make the library incrementing by one on the whole size of the IV, leaving boundaries aspects (the routine just don't care about the way the given IV was built) and associated overflow condition checks (the routine gives back the manipulated IV) to the responsability of the calling programs. I'm thinking this is the best general solution we can hope for. Also, we should explicitly include in the docs a warning to check the IV for overflow iff the counter is 64 bits. Richard, do you want me to write up the code change, or do you want to do it? 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 Richard Levitte - VMS Whacker [EMAIL PROTECTED] lee_dilkie (the other thing to remember is that CTR can be used with lee_dilkie any block cipher, it's not limited to AES) Absolutely. However, since it's currently very obviously an experimental field, and it was originally 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). I tested a bunch of different mode implementations, yes. Since some libcrypto ciphers implement the round function directly inside the mode loops (e.g. IDEA), there is no way to generalize modes and maintain performance. Others, such as AES, issue a function call and could be generalized, but the extra cost of calling a function pointer (vs a real function) is enough to outweigh the code savings. FWIW, the performance gains of switching from __stdcall to __fastcall is staggering (at least on x86); that alone blows away all the experimentation I did with MMX and SSE extensions, hand-tuned ASM, etc. When I saw that, I gave up on any further algorithm improvements, though I'm sure there's still small improvements to be made here and there. 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 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: Re: AES counter mode
Thus spake Thierry Boivin [EMAIL PROTECTED] http://archives.seul.org/mixminion/cvs/May-2002/msg00072.html shows that the problem seems to have been submitted to the openssl team one year ago.I agree with Nick and go to the same conclusion : as the openssl aes counter mode routines wants to count by 2**64 instead of by 1, the current implementation is not correct. The source of disagreement seems to be the interpretation of a NIST document (Michael pointed such a document when replying at first). 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. Further review has indicated everyone else seems to think this means the nonce is incremented only between streams and it's the counter that is incremented between blocks; is there anyone out there who _disagrees_ with this? If not, it is a trivial matter to shift which bits in the counter are touched. 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. To increment the nonce introduces a more insidious failure mode where the user unintentionally reuses nonces. Other specifications have suggested that nonce be of unspecified length, not exactly 64 bits; this implies that the lower bits wrap in an overflow condition, otherwise there would be no need to specify a boundary between the different parts of counter at all. 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. 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: [openssl.org #306] EVP_xxx_{cfb,ofb} problems in openssl 0.9.7-beta3
Are you speaking of the CFB-8 tests failing? I've only implemented
CFB-128 so far, so I'd expect CFB-8 to fail. If I'm reading things
right, Levitte's fix is for the EVP padding, not the crypto routines.
S
Thus spake Chris Brook:
Is this now fixed for EVP_Encrypt() and EVP_Decrypt() or only the
xxInit,xxUpdate,xxFinal sequences? Or must I set padding off?
If this is resolved, I can go back and rerun the NIST AES certification
tests for CFB with 8 bit block sizes. Needless to say they failed before.
Chris Brook
-Original Message-
From: [EMAIL PROTECTED]
[mailto:owner-openssl-dev;openssl.org]On Behalf Of John Viega via RT
Sent: Thursday, October 17, 2002 7:18 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [openssl.org #306] EVP_xxx_{cfb,ofb} problems in openssl
0.9.7-beta3
Yes, it does indeed seem to be fixed. Seeing that OFB and CFB are
pretty fundamental, shouldn't a fix like that merit a b4 release,
particularly considering how long it's been since b3? :)
John
On Thursday, October 17, 2002, at 05:34 PM, Richard Levitte - VMS
Whacker wrote:
In message [EMAIL PROTECTED]
on Thu, 17 Oct 2002 16:34:55 -0400, John Viega
[EMAIL PROTECTED] said:
viega Perhaps it would help to show you how things work differently
in 0.9.6
viega and 0.9.7. Try this code out in each one:
viega
viega #include openssl/evp.h
viega
viega int main(int argc, char **argv) {
viegaEVP_CIPHER_CTX c;
viegachar key[128] = {0,};
viegachar iv[128] = {0,};
viegachar in[256]={0,};
viegachar out[256];
viegaint olen,i, o2;
viega
viega #define CIPHER() EVP_bf_cfb()
viega #define HOWMANY 148
viegaEVP_EncryptInit(c, CIPHER(), (char *)key, iv);
viegaEVP_EncryptUpdate(c, out, olen, in, HOWMANY);
viegaEVP_EncryptFinal(c, out+olen,o2);
viegaolen += o2;
viegaprintf(Olen = %d\n, olen);
viegafor(i=0;iolen;i++) {
viega printf(%02x , (unsigned char)out[i]);
viega}
viegaprintf(\n);
viega }
viega
viega This returns 148 in 0.9.6, and it returns 152 in 0.9.7 (b3 at
least).
viega The same thing happens in OFB mode. What's going on is that
PKCS
viega padding is getting added when it never was previously.
Ah, yeah, right, that's a bug in beta3. It has been fixed, however.
Please try the latest 0.9.7 snapshot, and you'll see the difference.
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-168 35 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]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
--
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: CTR mode
My reading of Rogaway's CTR submission was a nonce in the top half of the counter with a simple increment (by one) of the whole counter. Is there a new spec we need to comply with? What is the correct behavior of CTR when it reaches 2^64 (or whatever lower limit IPsec et al may set)? I'd assumed that it was safe to wrap to zero and keep counting. Do you have a suggested implementation for how to set a lower limit? The modes should probably be written as macros, yes. Unfortunately, some cipher implementations don't call an ECB function but actually implement the cipher inside the mode; switching to mode macros will be very tricky. S Thus spake John Viega: It should be possible to replace the counter increment function. The new NIST modes doc doesn't specify a mandatory increment function, but it does recommend one that's different from add one every time. Additionally, a lot of stuff built on counter mode is using a few bits of the counter for other purposes, so the effective counter size is less than the actual counter size. It would be nice to be able to add some sort of parameter that specifies the actual counter size, to prevent counter mode from continuing to encrypt when it's run out of counters. Also, why isn't counter mode implemented in a generic fashion? It's so simple, it should be usable with any block cipher without having to write additional code. John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- 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: Moving towards autoconf
Thus spake Richard Levitte - VMS Whacker: In message [EMAIL PROTECTED] on Wed, 17 Jul 2002 13:33:09 -0500, Stephen Sprunk [EMAIL PROTECTED] said: stephen I'd like to take on moving OpenSSL towards an autoconf stephen system. First of all, if anyone else is working on this, stephen please let me know :) Others have done that, but it's so far not been a hot topic. The trouble with autoconf is that it's very sh-bound (or at least the end result is), which means is largely Unix-bound, and it generates a number of variables that are often difficult to keep up woth manually no the systems where autoconf and sh don't exist or work badly. Okay, I hadn't thought about VMS, Windows, etc. I'll come back when I have a better clue how to do it :) stephen Second, I'd like to move all OS-specific defines and includes to a stephen common place, such as openssl/common.h. This would hopefully stephen eliminate the need for openssl/e_os2.h entirely. Comments? So basically, you'd like e_os2.h to be renamed to common.h. Or did you want to throw in the stuff that you find in e_os.h as well? Not exactly. There's a lot of OS-specific pollution in the source tree proper. A first target would be elimination of the OPENSSL_SYS_system family and replacing it with HAVE_feature and HAVE_header_h. You need to understand that e_os.h is private to OpenSSL (it can mess things up if used outside of OpenSSL) while e_os2.h is the public part, so mixing them in the same file would be a bad idea. IMHO, stuff like this doesn't belong in the main sources: #ifdef OPENSSL_SYS_WINDOWS #define strcasecmp _stricmp #else #include strings.h #endif It's much easier for individual contributors to maintain this: #ifdef HAVE_STRINGS_H # include strings.h #endif And then the folks concerned with porting to a new OS would only have a single place to worry about: wherever the OS is translated into the HAVE_ macros. The reason to stay away from things likt uint8 is that it isn't standardised yet. On some compilers, __uint8 is available instead, on others it's u_int8 or u_int_8... Basically, we would have to define our own in terms of whatever we find out there... Here's something from the AES refence code; there are similar examples from most of the other crypto units: typedef unsigned long u32; typedef unsigned short u16; typedef unsigned char u8; On a variety of systems, you have no idea how long a long or an int is going to be, and that should be hidden in some generic header (like e_os[2].h) so that we can use uint32's in our code without worrying that we'll accidentally get a 16-bit or 64-bit int. ISO C95/99 define these pretty explicitly in stdint.h, and e_os[2].h should be able to hack around that on non-compliant systems. 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Gladman's Implementation in AES
Thus spake Ben Laurie: Satria Bakti (13297096) wrote: Hi, I'm doing some experiment on openssl-0.9.7-stable-SNAP-20020421. I replaced the AES code (the original AES code) with Brian Gladman's AES code (with some modification). (http://fp.gladman.plus.com/cryptography_technology/rijndael/) Can you send us the modifications you used? There are significant increases. I'm afraid that there is something wrong with my implementation. How could the speed increase so significant ? Any comments or explanations are welcome. Its possible, in fact - because what we have is the reference code, and Gladman's is optimised for speed. Of course, if the code passes the tests, then you must, presumably, have got it right. I haven't committed the AES test code yet, so we don't know if either implementation is actually correct. Are you planning to contribute your implementation (I'd been planning to look at this at some point myself). I'd have done it myself if I'd known Gladman's implementation was *that* much faster. I've been spending my cycles trying to make the various modes go faster, which should help most/all of the ciphers. 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Integration of AES algorith to OpenSSL Crypto library
Thus spake Ildar Gabdulline: Yes, I've got recent 0.9.7 snapshot but openvpn crashes when I link it with the snapshot. I am going to minimize scope of the problem as follows: 1. get stable 0.9.6 release 2. get only AES code and integrate it to 0.9.6 Perhaps you should figure out why openvpn is crashing instead of trying to re-do work which has already been done. AES is already integrated, so if there's a bug, let us know and we'll fix it. 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: -utf8 option
Thus spake Robert Joop: the explanation of the -utf8 option doesn't make sense, does it? quote src=http://www.openssl.org/docs/apps/req.html; -utf8 this option causes field values to be interpreted as UTF8 strings, by default they are interpreted as ASCII. This means that the field values, whether prompted from a terminal or obtained from a configuration file, must be valid UTF8 strings. quote ASCII is a proper subset of UTF-8, rendering the -utf8 totally superfluous? i guess what is meant is ISO 8859-1 instead of ASCII? I think the document means 8-bit characters in an unspecified code page instead of ASCII; however, there's no short term for that. (ISO 8859-1 and UTF-8 are conflicting encodings, whereas ASCII and UTF-8 are not.) Here's the more interesting question: why do we have a switch for UTF-8 encoding, instead of determining it from the user's locale? 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: re[2]: .NET version of OpenSSL
Thus spake Jeff Roberts: Paul, I know, I am an old Unix Programmer that now loves .NET ! As a matter of fact I was programming before Unix was around ! I seriously doubt someone as naive as yourself has been programming for more than 32 years. I have seen a lot of old Unix programmers end up in the unemployment line because they failed to change with the times and I am afraid this is just another case ! .NET is an interesting way for different applications and different companies to communicate; XML is an excellent low-performance data interchange format. Don't think this means every application or library will benefit from being rewritten to .NET (and in C#). You have a shiny new hammer; that doesn't make the wrench and screwdriver in your toolbox less useful. Learn to use all of your tools at the appropriate time and you will be more successful. I looks like OpenSSL will stay a mostly Unix product, which means it won't be an integral part of the Desktop since Microsoft own 95% of the desktop ! Again, you are free to write a C#/.NET wrapper around the OpenSSL DLL, but don't expect us to rewrite the entire source in C# just because you've fallen for MS's marketing material. 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: .NET version of OpenSSL
Thus spake jeff roberts: Is anyone working on a .NET version of OpenSSL ? For those of us that live in non-Microsoft worlds, can you explain what this means/entails? 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: re[4]: .NET version of OpenSSL
Thus spake Jeff Roberts: I think you can create .NET components in Java too ! The point is that there are going to be a lot of .NET applications that need a .NET solution. Some companies are porting their Java code to C# because it is so similar ! C# will never have the speed that C/ASM can achieve, and you're going to have a tough time convincing us to rewrite tens of thousands of lines of code just to make Bill Gates happy. There MUST be some way to link .NET code to non-.NET DLL's, so creating a C# wrapper around OpenSSL may be a worthwhile exercise. 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: AES, counter mode, etc.
Thus spake John Viega: Additionally, with respect to counter mode, it might be best to implement external to the EVP proper interface, just like HMAC. There are a few issues I see that make counter mode a bit different from other modes: 1) You should be able to insert your own function for choosing a stream of counters. They don't have to be simple incrementing counters. The CTR mode proposal to NIST specifies starting a 1 and doing a simple increment. Unless other counter types are provably more secure, I prefer not to foster incompatible implementations. 2) Counter mode can be used in a random-access manner. For example, if you encrypt a file with counter mode, you can then access the blocks of that file independently, as long as you know the counter value. Good point. If you set the counter manually (instead of starting at 0), this should work properly. Were you looking for a more elegant way of doing this, or is my API broken? 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: EVP macros for AES
Thus spake Dr S N Henson: Maybe. It would be good to the the CFB and OFB modes working properly in general for other numbers of bits. The code for this is trivial; define me an API and I'll write the code underneath. I thought about moving the whole cipher mode handling to the EVP layer and trimming down the individual block ciphers to just encrypt/decrypt a single block at one point. However tests suggested that this would have a considerably impact on performance so we're probably stuck with the duplicate mode code for now. I'd like to see exactly where the performace problem was; I can't imagien it'd be statistically significant. There is some duplication in individual cipher modes and some macros might help though there is some variation where some cipher optimize the storing of things like the IV in the most effective internal format. All of these optimizations seem to revolve around endianness problems or char/uint64 representations. I wonder if we could do better by moving some of the mode handling to the assembly language routines and take advantage of some special cases to avoid function call overhead. I tried this for AES and got ~10% speed increase for CBC in about 5 minutes using some generic assembly. Another 17% by throwing some MMX stuff in over my lunch hour. And I haven't even touched the C algorithm itself :) Again, it's not worth doing this for each algorithm/mode, but if we had either a mode API or at least macro sets, it would be. 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: AES, counter mode, etc.
Thus spake John Viega: When I looked at the AES API, it looked like there was no way to specify a block size independently of the key size. Is that intentional? The NIST FIPS specifies AES with a 128-bit block size. Rijndael can be used in many other ways, but there is a significant performance loss in flexible implementations. 192- and 256-bit blocks may be added in the future, but there's higher priorities at the moment. Additionally, with respect to counter mode, it might be best to implement external to the EVP proper interface, just like HMAC. There are a few issues I see that make counter mode a bit different from other modes: Already under discussion, though in reference to ALL modes :) 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 __ 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: From: Stephen Sprunk [EMAIL PROTECTED] stephen After implementing CBC, CFB, OFB, and CTR for AES (mostly plagiarized stephen from IDEA), I'm beginning to wonder why we have 40 different stephen implementations of the exact same algorithms in the first place. stephen Couldn't we have a general modes macro set, to which you pass the stephen ECB function of the cipher you're using? The current state is EAY legacy. His idea was that one should be able to pick out any of the algorithm directories and create a separate library for them (the old libdes is actually exactly the same as crypto/des/). First of all, do we still think that's necessary, given the wide acceptance of OpenSSL and libcrypto? In either case, it shouldn't be that difficult to develop a macro set that implements various modes. Pass in some function names, block size, types for casts, and let it generate the boilerplate. Worth doing? 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Pentium Pro compiler optimizations
Thus spake Tim Rice: 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. It sounds like your cc has a nasty bug; why not use gcc? I regularly use gcc -O3 -march=pentiumpro -fschedule-insns2; there is currently a bug when you mix -fschedule-insns (not 2) with -O2 or above. This is at least 10% faster than the default -mcpu=pentium that OpenSSL uses on my box. 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 __ 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
Thus spake Wei Dai: I'll note that using CTR mode is more efficient than either of these suggestions. It doesn't require unpredictable IVs. ... Good point. If we want to fix SSH by using a per-packet unpredictable IV, the IV would have to be added to the list of MAC inputs. I think that would prevent the attack in appendix C. So is the correct approach to fix the CBC implementation, or to switch to a mode that is less prone to misuse? I'm not very familiar with how IETF working groups work, so what's the next step here? Someone writes an internet-draft (ie. RFC format) describing the change. 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: EVP macros for AES
Thus spake Dr S N Henson: 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. That's roughly what I figured :) After implementing CBC, CFB, OFB, and CTR for AES (mostly plagiarized from IDEA), I'm beginning to wonder why we have 40 different implementations of the exact same algorithms in the first place. Couldn't we have a general modes macro set, to which you pass the ECB function of the cipher you're using? I've also been at a loss for how to use SSE/MMX registers to pass around keys and blocks, since doing so would grossly violate the current API. This would provide serious performance gains, however. 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 __ 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
Re: AES support
Thus spake Subramanian Ramamoorthy: It appears that openssl-0.9.6c does not support AES. Will 0.9.6c at anytime include support for AES at a later time. If so, can anyone give an idea when this support will be included in 0.9.6c. AES will be supported in 0.9.7. 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
EVP macros for AES
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. 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: When do OpenSSL support AES cipher?
Thus spake ¹ÚÀçµ·: Can you please clarify me on the following. It's known and obvious that DES is no more strong. I am curious about when OpenSSL librarys start supporting AES cipher instead of DES? 0.9.6c (the latest public release) has primitive support for AES (Rijndael). 0.9.7 will have much more robust support. 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Where can I get the the 0.9.7 version?
Thus spake Maya: I want to use req with UTF8? From the dociment it's seems that UTF8 can be used only with 0.9.7 version. So I wonder where I can get it? 0.9.7 hasn't been released yet. In the meantime, you can experiment with the snapshots or CVS tree. 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: When do OpenSSL support AES cipher?
Thus spake Richard Levitte - VMS Whacker: From: Stephen Sprunk [EMAIL PROTECTED] stephen 0.9.6c (the latest public release) has primitive support for stephen AES (Rijndael). Really? Really really? Have you looked? I've got *way* too many different copies of openssl on my machine. I stand corrected. Rijndael appeared in early port-0.9.6 snapshots. This really isn't my week. 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
integration (was: Re: Adding a new hardware accelerator)
Thus spake Richard Levitte - VMS Whacker: You send the changes to [EMAIL PROTECTED] I can't guarantee that it'll get, since that depends on both time and policy. Speaking of that... Any reason my AES patches didn't make it into the cvs tree? I thought I submitted them properly. 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: integration (was: Re: Adding a new hardware accelerator)
Thus spake Ken Murchison: It looks like they are there to me: http://www.openssl.org/source/cvs/crypto/aes/README?hideattic=1sortbydate=0 Slipped past me when I wasn't looking... Nevermind :) I keep looking if/when aes-ofb support arrives :^) It'll be ready in a couple days. 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: maximum password length in crypt() function.
Thus spake Hari: Hi all, I use openssl-0.9.6 on a RedHat Linux 7.0 system as well as LynxOS system, both on i386 machines. I use the crypt() function defined in (ssldir)/crypt/des/fcrypt.c The output of crypt remains same for passwords with the same first 8 characters. I would like to know the maximum length of the password argument to crypt(password, salt) function. It's historically been 8 characters maximum in crypt()-based systems. Per the crypt(3) man page: By taking the lowest 7 bit of each character of the key, a 56-bit key is obtained. While it's not openly stated, anything after the first 8 characters will be ignored, as are the highest bits of those characters. 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Simple question
Thus spake Michael Trebilcock: If i compile OpenSSL, with just ./configure, make, make install, archive that, then send it to somewhere in the U.S, can the site/ftp in the U.S legally distribute it internationally? What about other countries? A yes or no answer would be nice, or an i'm not sure if you don't know.. IIRC, only freely distributed source code is currently granted a blanket license for export from the US. Object code still requires a license. 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[PATCH] aes integration (2nd try)
Okay, here's my first stab at some improvements to AES integration. . apps/openssl speed now supports aes options, works just like des. . improved efficiency of EVP calling AES . substantial AES API cleanup Coming soon: . 128-bit CFB and OFB modes . Support in more apps/openssl programs . MMX ASM code I'll leave renaming rijndael.h and crypto/rijndael/ to someone with more CVS skill :) cvs diff -Nu is at: http://defiant.dfw.nostrum.com/~sprunk/aes.diff.bz2 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OFB mode for AES
Thus spake Ken Murchison: Are there any plans to add OFB mode support to AES? Most, if not all of the other ciphers have support for OFB, but AES does not. I'll add CFB and OFB as soon as my other patches make it into the snapshots. Do you need 64-bit, or will 128-bit work? 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
AES work
I'd like to offer some work on integrating AES (Rijndael), based on the inital work I see in the snapshots. However, I'm in the US. How can I help? 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 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
