I agree with most of that. However, based on benchmarks on my desktop (a
Core 2 Duo E6400) the 32-bit x86 assembler mont exp implementation in
OpenSSL seems a _lot_ slower than my GPU.
Of course your CPU is a lot slower to perform 2048 signs, but it's a lot
faster to perform one. I mean if you
Hello dev team.
Jouni Malinen recently posted here with a patch that adds support for various
features required in OpenSSL to support new authentication protocols like
EAP-FAST and others.
I want to confirm that his patch applies cleanly to openssl-SNAP-20070816 and
works as intended.
I want
Of course your CPU is a lot slower to perform 2048 signs, but it's a lot
faster to perform one. I mean if you simply don't get more than 1 sign
request within 240ms and if you insist on always using GPU, you'd have
to ask it to perform 1 real and 2047 bogus signs. And so you'll have GPU
spending
Hi.
I posted this a while ago on openssl-user, maybe it was not
the right place since nobody reacted.
Annoyed by having the time part of notBefore and notAfter fields
set to the time I run the command, I hacked a -cleartime option
to openssl x509 and openssl req -x509.
I attach
The obvious application is web serving, which I assume (perhaps naively)
accounts for a substantial majority of private decrypts performed using
openssl
While this data isn't applicable to the internet as a whole it may
provide you with some insight into this.
The obvious application is web serving, which I assume (perhaps naively)
accounts for a substantial majority of private decrypts performed using
openssl
While this data isn't applicable to the internet as a whole it may
provide you with some insight into this.
I haven't seen this added to the development snapshots, so I'm
submitting a working Configure statement for Mac OS X x86_64 (64-bit) :
darwin-x86_64-cc,cc:-arch x86_64 -O3 -fomit-frame-pointer -fno-
common -DL_ENDIAN -DMD32_REG_T=int -Wall::-
D_REENTRANT:MACOSX::SIXTY_FOUR_BIT_LONG
Andy Polyakov wrote:
http://netflow.internet2.edu/weekly/20070820/
Given this context I have to admit that I have effectively misused
throughput term in my posts. I should have written amount of private
key operation requests per time unit and speculate about its effect on
overall
I haven't seen this added to the development snapshots, so I'm
submitting a working Configure statement for Mac OS X x86_64 (64-bit) :
darwin-x86_64-cc,cc:-arch x86_64 -O3 -fomit-frame-pointer -fno-common
-DL_ENDIAN -DMD32_REG_T=int
-Wall::-D_REENTRANT:MACOSX::SIXTY_FOUR_BIT_LONG RC4_CHUNK
On Aug 29, 2007, at 11:57 AM, Andy Polyakov wrote:
I haven't seen this added to the development snapshots, so I'm
submitting a working Configure statement for Mac OS X x86_64 (64-
bit) :
darwin-x86_64-cc,cc:-arch x86_64 -O3 -fomit-frame-pointer -fno-
common -DL_ENDIAN -DMD32_REG_T=int
Next time you have such big post of restricted interest for all
subscribers, send it only to me. Thanks.
Shared build is likely to fail. Can you confirm if following works:
darwin64-x86_64-cc,cc:-arch x86_64 -O3 -fomit-frame-pointer
-DL_ENDIAN -DMD32_REG_T=int
On Aug 29, 2007, at 12:33 PM, Andy Polyakov wrote:
Next time you have such big post of restricted interest for all
subscribers, send it only to me. Thanks.
Shared build is likely to fail. Can you confirm if following works:
darwin64-x86_64-cc,cc:-arch x86_64 -O3 -fomit-frame-pointer -
The hpux-parisc2-cc configuration still uses the dlfcn specifier (see
below), it must be renamed to dl as in the other parisc targets.
64-bit PA-RISC is ELF and implements dlfcn-style API. Even though
dl-style API is supported in 64-bit context users are encouraged to
migrate to the dl*
After successfully configuring and building OpenSSL version openssl-0.9.8e
on Sun/Optron under the latest Soalris 10, after executing:
make test
The following errors are detected:
Testing cipher AES-128-ECB(encrypt)
Key
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
The problem was the setting for linux64-sparcv9 within Configure.
Minimum change needed to fix problem:
SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL
BF_PTR:::des_enc-sparc.o fcrypt_b.o
i.e. the addition of DES_INT is enough to fix the problem.
The following code should
On my old Debian box during OpenSSL 0.9.7 build, make fails:
make[2]: Entering directory `/usr/local/openssl/crypto/rand'
gcc -I.. -I../.. -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHA VE_DLFCN_H -DOPENSSL_NO_KRB5 -m64 -DL_ENDIAN -DTERMIO -O3 -Wall
-DMD32_REG_T=int
0.9.8-stable-SNAP-20070829 succeeds for both shared/non-shared using
darwin64-x86_64-cc :
[non-shared]
chani:/usr/local/build/openssl-0.9.8-stable-SNAP-20070829 sheurich
$ ./Configure darwin64-x86_64-cc make make test
Configuring for darwin64-x86_64-cc
no-camellia [default
This transaction appears to have no content
Hi Andy:
By removing "-fast" option of Solaris native C compiler, the error
disappeared.
Shawn Ayromloo
Andy Polyakov via RT wrote:
After successfully configuring and building OpenSSL version openssl-0.9.8e
on Sun/Optron under the latest
18 matches
Mail list logo
