RE: 0.9.8: cfb_enc.c bug? and AES speed on Win64/x64

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

AES CTR mode implementation

. Regards, David C. Partridge Technical Products Director Primeur Security Services Tel: +44 (0)1926 511058 Mobile: +44 (0)7713 880197 __ OpenSSL Project http://www.openssl.org Development Mailing List

RE: AES CTR mode implementation

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

RE: [openssl.org #1096] Minor documentation bugs

The problem with pthread_self() is that the value it returns is defined to be opaque, and isn't necessarily (e.g.) and unsigned long (32 bit), though many Unix and Unix like systems do use a 32 bit value ... Dave __ OpenSSL

RE: OpenSSL use of DCLP may not be thread-safe on multiple processors

Thanks all. It strikes me that the H/W designers have played a bit fast and loose with the cache consistency issue here - I believe I understand the C/C++ optimisation issues, and these CAN be worked around (IMHO) within the rules of the standard by using bool in some cases. However I've

RE: OpenSSL use of DCLP may not be thread-safe on multiple processors

oops ... First test should of course read: Singleton* Singleton::instance() { if (!initialised) // 1st test -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David C. Partridge Sent: 06 April 2005 14:08 To: openssl-dev@openssl.org Cc: [EMAIL PROTECTED

RE: OpenSSL use of DCLP may not be thread-safe on multiple processors

ARGH! Are you absolutely sure that this is the case - that's scary - I thought that the whole issue of SMP cache coherency and write order was solved years ago. I mean that if the order of memory write visibility between processors can't be g'teed, than a whole lot MORE than just DCLP

RE: query: Private Key generation using OpenSSL

Any random data that is shared with the recipient will do as a key for HMAC Dave __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org

RE: ENGINE issues

IIRC the Luna CA3 is FIPS140-2 LEVEL 3 which means it won't allow you under nay circumstances to extract the private key from the device (non-extractable, sensitive in PKCS#11 parlance). What this means is that you need to send the data to the device to be signed (don't know how to do this using

RE: OS/2 support

Gosh there's a blast from the past! I remember your name from *way* back when I used to work on OS/2. How are you? Anyway to the chase: IIRC you just need to patch to replace the strncasecmp with strnicmp, and strcasecmp with stricmp ( or do conditional compilation). Dave Partridge

RE: [openssl.org #502] TXT_DB error number 2

The renaming of the serial file is a known bug. See my recent post to openssl-dev Dave __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED]