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
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
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
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
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
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
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
-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
{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;
