Re: First (initializing) call to RAND_status() very slow on Win32
Ferdinand Prantl wrote: [...] What is interesting, 471 heap entries takes much more time than 506 thread entries. OK, I can understand the slowness, if many big heaps are present; this code is run the worst count_of_heaps * 80 times: RAND_add(hentry, hentry.dwSize, 5); [...] I myself have never seen such a slow RAND_poll, so I'd think the problem has to be located somwhere on your computer. Well, I solved it for me by patching the openssl in our production as our release draws nearer and nearer. I am attaching the file with the extended logging and the diff to rand_win.c which turns the heap-walking off, if anyone are interested. I can also test it further, should you like to have more information. thank you, Ferda My solution as well. On some machines, running a large number of applications with long heap chains, the startup delay was totally unacceptable (sometimes on the order of 30 seconds for slow h/w). Unfortunately, this is one of those field found issues as developer and test machines seldom natuarally have these configurations (and a bugger to track down). I also question the usefullness of such an entropy source, especially if it contains such a performance hit. I think a solution that marries entropy gathering with startup time might be nice, ie. watch the clock as you walk those lists and bail early if it's taking too long. -lee __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #854] randfile.c doesn't complile on some platforms
I apologize for my first rt bug report, it was missing some important details. this was the 0.9.7d version of the source tarball. compilier was gcc.something.really.old.that.vxworks.still.uses compiling for PPC (if that matters but i don't think it does). the S_IBLK code section mentioned was added between 0.9.7c and 0.9.7d. -lee -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of via RT Sent: Monday, March 22, 2004 1:00 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [openssl.org #854] randfile.c doesn't complile on some platforms Due to the inclusion of S_IFBLK logic in RAND_write_file (crypto/rand/randfile.c) a later declaration of int fd =... fails to compile on some older, stricter, compiliers. see patch for solution, basicly a declaration of int fd located with the other declarations. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Slow heap walking in rand_win.c
You can always implement your own source of random data and push it into the OpenSSL engine. If you do that the rand_win code will not be executed. Jeffrey Altman As far as I can tell from reading rand_win.c and md_rand.c, this is not the case. Calling any of the useful rand functions, see ssleay_rand_status() for example, results in RAND_poll() being called because the global initialized is not set. RAND_poll() calls the heapwalking stuff in windows. Calling ssleay_rand_add() (same as RAND_add) does not set the initialized flag so there is no way to stop the lengthy heapwalk without hacking the source. Please correct me if I'm wrong. regards, -lee __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Slow heap walking in rand_win.c
I do not actually believe that a one time 30 second delay during process initialization is inappropriate for a security application. In the discussions that are being held with regards to the use of AES in conjunction with Kerberos there is a belief that 30 seconds should be the minimum amount of time taken to perform the crypto operations for processing a password to key operation. This is to ensure that there is not the opportunity for offline dictionary attacks on passwords. that's fine for that particular application. I don't believe the ssl library should enforce such excessive requirements on applications seeing that it has no knowledge of what the application is doing or what level of trust/privacy it requires. I don't have a problem with a library providing strong methods of generating entropy but forcing every application to endure a 30 second delay is excessive. The 30 second delay for random key data initialization does not have to be a blocking operation for the initialization of the application. It can be done in parallel to other operations your app requires unless the first thing that is performed are SSL/TLS operations. And if it is, like mine was, then your application just sits there looking hung to the user. Which means it's a PITA and doesn't get used. I also wonder what it is that your application is doing at initialization time that results in a heap size of greater than several well, it's a bit more complicated than that. all the heaps of all the processes are walked. They don't have to be big, just lots of them. Which is why this isn't a problem on some systems running few processes or with small heap list lengths and is a big problem on others systems (desktops of power users, for example). My Solution... I hacked the code to get rid of the heap walk and just used the entropy from the process, thread and module walk. My application didn't need that paranoid a level of security. But personally, I think these methods should be exposed openssl library calls that the application can pick and choose. -lee __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Please give me an answer [AES counter mode]
I'd really like an answer to my question: does the patch I presented to you constitue a good enough implementation of what has been discussed and concluded here (basically, the patch makes AES-CTR increase the IV with 1 after each block)? Looks like it'll work for me too. thanks, -lee __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: AES counter mode
CTR mode offers very little advantage over CBC or CFB or OFB -- the motivation for IPsec was very high speed, parallel encryption with precomputation of the keystream (according to the Rt. Hon. Rev. Bellovin, IETF Security Area co-chair). A very important consideration for ultra high performance h/w ipsec implementations. Chaining modes like CBC just simply cannot go fast enough. It was also important for secure RTP, not for performance so much but for the alility to not have to pad plaintext out to an even blocksize of the cipher when using a block cipher (such as AES). This was very important for them because those tiny RTP packets would get expanded a lot when encrypted in a CBC mode. Stream ciphers could not be used for other reasons (packet reordering/loss, for example). Now.. Why SSL/TLS would need this mode is a bit more questionable.. ? I was just chiming in because OSSL's crypto libs are used for lots of non-SSL applications. -lee __ 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: AES counter mode
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Maurus Sent: Tuesday, June 24, 2003 7:29 AM To: [EMAIL PROTECTED] Subject: Re: AES counter mode The easiest way to go about it would be to increment the user 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. Agreed, just increment the user supplied IV, it's the most general approach and will work for all the protocols that need ctr mode but can't (shouldn't) agree on nounce/counter boundries. -lee __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: AES counter mode
{jumping into a discussion somewhat late...}
I don't have experience with counter mode for SSL (if there is even such a
beast) or the NIST mode you are referencing (I believe Ipsec was looking at
that mode a few months ago) but I do have experience with counter mode for
SRTP (secure RTP; encryption of media streams). In fact, I wrote a counter
mode encryptor/decryptor using the EVP_* functions.
Counter mode for SRTP is a little different in that the counter part, the
part that increments for each keystream block (128 bits, for AES) is only
the lower 16 bits (rtp packets just don't get larger than that...) and the
application supplied starting count value (refered to as the packet IV in
SRTP) consumes 112 bits, starting at bit 16.
In general, the most flexible approach would be to provide an aes counter
encrypt function that took a 128 bit starting value (IV), incremented (+1)
it as many times as necessary to form the keystream (dependent on the size
of the buffer that needs encrypting), and performed the encryption and
subsquient xor'ing operation. As far as I can tell, the low bits that are
incremented will *not* overflow, by design, into the upper bits.
It should be up to the calling application to provide the 128 bit 'IV' for
each call to aes_ctr_encrypt(). You shouldn't need any AES_incr_ctr()
function. It's a little messier but it is more flexable and doesn't make
assumptions on where the counter ends and the IV begins.
(128 bit integers are a bit scarce to come by, I used char buffers myself,
which had the advantage of keeping things in network byte order as well).
There was one more generalization that I considered when the incrementation
value (+1 or +164) was still under discussion and that was to have the
application provide the increment value as well but this has performance
impacts.
-lee
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Richard
Levitte - VMS
Whacker
Sent: Monday, June 23, 2003 12:36 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: AES counter mode
In message [EMAIL PROTECTED]
on Mon, 23 Jun 2003 18:22:37 +0200, Thierry Boivin
[EMAIL PROTECTED] said:
Thierry.Boivin My understanding of this one is (in a
practical perspective) is :
Thierry.Boivin calling programs maintain a 64 bit long nonce
counter. This counter is to be incremented by one from
messages to messages. As this nonce is used to form the high
part of a 128 bit long counter value -- we add 0 for the low
part -- , the counter element is globally incremented by
2**64 from messages to messages. This is for the behavior of
the calling program. If considering the routine implementing
the message encryption (so the openssl routine), message is
to be split into blocks and each block encrypted with a
specific counter value : first block is used with the initial
counter given by the application (64 bit long value 64 + 64
bit long zeros.). Next blocks of the message are then
encrypted using a counter value of blockN = counter value
of blokcN-1 + 1 operation.
And when should the increment by 2^64 occur? Is that something that
the application should make sure happens with some kind of call to the
currently non-existing functino AES_incr_ctr() (perhaps done in
EVP_EncryptFinal())?
If everyone can agree on such an interpretation, I have no problems
changing it, as long as it also makes the implement crunch the
available test vectors properly.
--
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]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
