Tomas Svensson wrote:
|
| Some OpenSSL-algorithms are slower on x64, like RSA. SHA1 and RC4 seem to
| be faster [...]
Cases where an OpenSSL algorithm is slower on AMD64 than on i386 are
almost always due to a substandard AMD64 implementation. For example,
some algorithms are written using
Instead of doing what was intended, moving the string up one place, the
code has different behaviour.
Yes, it will fill the buffer with H which is what I would expect to happen
- not immediately obvious, but sensible. (any 370 assembler guys will
recognise MVC as doing this).
If you want to
David C. Partridge writes:
If you want to copy from one mem location to another even if they overlap
*and* preserve the contents, then you should use memmove and pay the
overhead of the temporary buffer it probably allocates.
Just a note: memmove doesn't need any temporary storage. It just
| Some OpenSSL-algorithms are slower on x64, like RSA. SHA1 and RC4 seem to
| be faster [...]
You said that RSA is slower on AMD64 ?
This is not what he said. The claim was that RSA is slower on *EM64T*
core and Win64 and this is not surprising. First of all note that 64-bit
C implementation
Do note [when] num [as in memcpy(ovec,ovec+num,8)] is guaranteed to
be positive. Question was can you imagine memcpy implementation that
would fail to handle overlapping regions when source address is
*larger* than destination? Question was *not* if you can imagine
memcpy implementation that
In message [EMAIL PROTECTED] on Thu, 7 Jul 2005 11:01:11 +0200, Corinna
Vinschen [EMAIL PROTECTED] said:
vinschen The problem only happens on filesystems which are not
vinschen case-sensitive but only case-preserving, like filesystems on
vinschen Windows or MacOS.
vinschen
vinschen What happens
Hello!
On Thu, 7 Jul 2005, Andy Polyakov via RT wrote:
Sorry, I've forgotten to mention I use 20050627 snapshot and
./config -g shared zlib works fine.
Yet I find it a bit too puzzling... After I've replied I came to realize
that no-sse2/386 shouldn't actually affect the referred test
Hello!
On Thu, 7 Jul 2005, Andy Polyakov via RT wrote:
Sorry, I've forgotten to mention I use 20050627 snapshot and
./config -g shared zlib works fine.
Yet I find it a bit too puzzling... After I've replied I came to realize
that no-sse2/386 shouldn't actually affect the referred test
I've been looking at the AES CTR mode implementation in 0.9.7
The counter increment function blindly assumes that the counter value can be
incremented across the whole 128 bits of the counter block.
If you look at (e.g.) RFC3686 or the NIST 800-38A publication, then they
both envisage a counter
On Jul 8 12:14, Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Thu, 7 Jul 2005 11:01:11 +0200, Corinna
Vinschen [EMAIL PROTECTED] said:
vinschen The problem only happens on filesystems which are not
vinschen case-sensitive but only case-preserving, like filesystems on
The counter increment function blindly assumes that the counter value can be
incremented across the whole 128 bits of the counter block.
Correct, which is why it's called AES_ctr128_*.
If you look at (e.g.) RFC3686 or the NIST 800-38A publication, then they
both envisage a counter block that
Please do not use previously mentioned routine, it missed 1 corner
case where 32=num_bits_word(d)
Revised routine that passes (cd test; make bntest).
Does it mean that previous version didn't actually pass the test? I mean
if it did on your CPU, but not mine, probably we could learn
Forgive my lack of knowledge in your existing code. But it is really
designed with optimization in mind? What was the driving force for
the C function?
If it is optimized what is the time required?
I jumped way to early at the fast conclusion I must admit. Because I
really never had speed in
800-38A essentially says up to impementator, doesn't it?
The standard incrementing function can apply either to an entire block
or to a part of a block.
Hmmm OK I do see you point here. I was sure I'd seen a discussion on the
net about this saying that it was dangerous to (e.g.) start the
David C. Partridge writes:
Hmmm OK I do see you point here. I was sure I'd seen a discussion on the
net about this saying that it was dangerous to (e.g.) start the counter at
zero, and that a nonce should be built in, and that this part should remain
constant. But, now that I've gone
On Fri, 8 Jul 2005, Andy Polyakov wrote:
Do note [when] num [as in memcpy(ovec,ovec+num,8)] is guaranteed to be
positive. Question was can you imagine memcpy implementation that would
fail to handle overlapping regions when source address is *larger* than
destination? Question was *not* if
Hmm. I am sort of jumping into the middle of things here. The question
is how portable the code needs to be? If it's using inline assembly,
It was *not* using inline assembly, but function which is *known* to be
implemented as intrinsic by *a number* of compilers. So it was portable,
yet
For reference, note that Linux version avoids __intel_fast_memcpy with
-Dmemcpy=__builtin_memcpy, because libirc.a caused griefs when linked
into shared library. __intel_fast_memcpy feels as overkill in OpenSSL
context and inlined code [movs or unrolled loop] should do better job.
Can you try to
(gdb) bt
#0 0x281330a1 in bn_mul_add_words () from ./libcrypto.so.0.9.8
(gdb) info r
eax0x30281d48 807935304
(gdb) disassemble
Dump of assembler code for function bn_mul_add_words:
0x28133090 bn_mul_add_words+32: call 0x28133095
bn_mul_add_words+37
0x28133095
Hi,
RFC 3686 is specific to IPSEC and using AES-CTR as the algorithm for
their encapsulated security payload. To me, the RFC indicates a 32 bit
counter (when all they really need is 28 bits) to handle the IPV6
jumbogram.
From the RFC 3686:
.
.
.
Block Counter
The block counter field
Hi everybody,
I tried to compile OpenSSL v0.9.8 inside Windows with
MingW environment inside MingW's MSYS environment
(this is a small unix like environment like cygwin, but much
smaller and native to windows).
So I did it the usual Unix way:
./Configure no-engine mingw
make PERL=$(which perl)
On Jul 8 22:08, Matthias Mohr wrote:
Hi everybody,
I tried to compile OpenSSL v0.9.8 inside Windows with
MingW environment inside MingW's MSYS environment
(this is a small unix like environment like cygwin, but much
smaller and native to windows).
Just for the records. MSYS *is* Cygwin,
Just for the records. MSYS *is* Cygwin, a branch from a very old
version of Cygwin. It's no way more or less native than Cygwin
itself.
Maybe - but without any cygwin.dll and the compiler chain and other tools
also don't need any cygwin.dll.
And they also don't need any special flags (like
On Fri, 8 Jul 2005, Matthias Mohr wrote:
I tried to compile OpenSSL v0.9.8 inside Windows with
MingW environment inside MingW's MSYS environment
(this is a small unix like environment like cygwin, but much
smaller and native to windows).
So I did it the usual Unix way:
./Configure
24 matches
Mail list logo
