Re: [patch] Valgrind complaining about unitialized data

Yes, it's desirable that that data is unknown however there is a compromise possible: Complement the area. It'll mean valgrind will only complain at the correct place, or possibly not at all, and it's still random. The performance hit from doing that will be so small it won't matter. This annoyed

RE: [patch] Valgrind complaining about unitialized data

Yes but: If you use Purify you have to recompile anyway to instrument the code. Valgrind runs on unmodified binaries - and it's not always possible to get someone else to recompile their code so that you can find problems. OpenSSL is used in commercial products where source isn't always

Re: [patch] Valgrind complaining about unitialized data

to openssl-dev Peter Waltenberg wrote: Valgrind runs on unmodified binaries - and it's

Re: crypto/mem_clr.c is not thread safe

I wouldn't have thought so no. The more garbage that gets written the better, provided it gets written to the right place that is. FWIW. There's a measurable performance increase reverting that to memset() and adding tests to ensure that the compiler hasn't in fact optimized it away. Peter

Re: [openssl.org #1585] NIST CMAC, AES-CCM and AES-GCM modes

, ~Aaron Christensen On 10/5/07, Peter Waltenberg via RT [EMAIL PROTECTED] wrote: (See attached file: ibm.patch) This contribution has complied with both local (Australian) and US export requirements (as IBM is a US based company) and is donated to the OpenSSL project under the terms

Re: [openssl.org #1585] NIST CMAC, AES-CCM and AES-GCM modes

AES_CCM has a real well duh! type bug on systems where long is 32 bits. The compiler will probably tell you where it is. Sorry - fix it a couple of days. Peter Peter Waltenberg __ OpenSSL Project

RE: aes-128-cfb1 bug

Yes, cfb1 is just plain ugly. Because the EVP layer expects bytes, but cfb1 (by design) expects bits it gets really nasty. I did manage to get cfb1 to pass the NIST AES test suite, but only by messing with the data at input and output - and even then I doubt that it's really working properly via

Re: PKCS#11 wrapper around OpenSSL

There are some things that are quite hard problems doing it the other way round. FIPS certification with the OpenSSL engine plugin active is probably the worst. With PKCS#11 on top of OpenSSL you have an industry standard API, which most hardware cards support. So you could swap a FIPS certified

Re: PKCS#11 wrapper around OpenSSL

On 2007.11.19 at 20:46:36 +1000, Peter Waltenberg wrote: There are some things that are quite hard problems doing it the other way round. FIPS certification with the OpenSSL engine plugin active is probably the worst. With PKCS#11

Re: PKCS#11 wrapper around OpenSSL

The only problem you might have with opencryptoki is that it can be hard to build, and it can be interesting to configure the first time - BUT it matches hardware cards in that. As far as extending the algorithms go - check the PKCS#11 specs, make sure the algorithms you want are already present,

OpenSSL test dir and dummyfile

Anyone know what trips dummyfile being symlinked over files in the tests subdir ?. And more importantly - how to prevent that happening. Thanks Peter __ OpenSSL Project http://www.openssl.org

Re: [openssl.org #1565] [PATCH] New port for the iSeries (AS/400) for version 0.9.8e

We do have OS 400 patches for 0.9.8e, but I have no OS400 hardware and won't be able to help a lot if there are problems. Peter From: Ronald Ojakian via RT

Re: OpenSSL FIPS Object Module v1.2

and I'm sure I forgot something there. HP/UX Itanium, Solaris X86/X86_64. Linux PPC, PPC64 , zSeries 31 and 64 bit ... I could find time and machines to test a few of the platforms as well if it'll help weed out build issues. We also have code to test against the sample NIST test vectors, that's

Re: building openssl tests

are seriously worried. Peter Peter Waltenberg From: Harmon, Paul [EMAIL PROTECTED

Re: Openssl AIX-64 bit build hangs

/as -u -a64 -mppc64 -o /tmp//ccxeRF7B.o aix_ppc64.s --- The assembler version is 5.1 could someone help me with figuring out whether my compiler / assembler is missing any patches? Appriciate any help in this regard. ~ Urjit - Original Message - From: Peter Waltenberg [EMAIL

Re: Openssl AIX-64 bit build hangs

PROTECTED] To: openssl-dev@openssl.org, Peter Waltenberg/Australia/[EMAIL PROTECTED

Re: OpenSSL performance woes with ubsec crypto engine (Broadcom BCM5820/BCM5823/BMC5825/BMC582x)

OPENSSL_cleanse() doesn't zero memory regions, it fills them with pseudo-random data. Edit crypto/mem_clr.c and replace that code with memset(ptr,'\0',len); and just clear the region - you'll see a significant performance boost if that's your majorbottleneck. Just be aware that some hypothetical

Re: Certs with ECDSA + SHA256

Er O.K. hash +padding is too large for the ECC keysize. Which it almost certainly will be since the larest ECC key defined is 521 bits. Peter From: Massimiliano Pala

Re: 64 bits computer always returns the same salt

It happens here on my 64 bit Linux system as well if I run the openssl that comes with the OS. However, if I run the openssl executable that I build for our own use (which has been modified to use our own RNG code) the salt varies as expected. Peter

Re: valgrind and openssl

It doesn't matter. If you only have one bit of real entropy you are screwed - no matter whether 0 or a 10^15 bits of known data are introduced, and if it's 10^15 bits of data the attacker can't reliably guess, you are definitely better off. And, to put this in perspective, given that the

Re: valgrind and openssl

Think back to what tripped this whole discussion. valgrind isn't complaining because the data has been pre-filled, it's complaining because it's never been touched. i.e if it were attacker providable buffer contents then this whole discussion wouldn't have happened. If the attacker can pre-seed

Re: valgrind and openssl

Subject:Re: valgrind and openssl Peter Waltenberg wrote: Think back to what tripped this whole discussion. valgrind

Re: Please help: very urgent: Query on patented algorithms

FWIW. The patent on MDC2 has expired. Peter From: Theodore Tso [EMAIL PROTECTED]

Re: Engine development/details needed

Hash isn't usually worth doing in an engine. It's usually so fast in software that the overhead of getting data on and off the accelerator usually means it's a net loss. In many cases that's true of symmetric ciphers as well. And when you hear words like CPU offload thrown in, you really need to

Re: FIPS certification document for OpenSsl

With more than one user on the machine there are a lot of potential out of band ways to subvert the crypto. Timing attacks, /tmp races, swap space attacks or just plain hacks and attaching a debugger to the running process. With this restriction the risks from most attacks which can't be dealt

Re: [openssl.org #1736] Enhancement Request: do away with error in chil engine in absence of dynamic locks

You need to be really careful here. Simply being dependent on pthreads and linking to non-threaded code is pure poison on some OS's. (HP/UX variants come to mind). If you do decide to add a default set of thread callbacks, you'll at least need a build configuration to disable it - I'm only

Re: [openssl.org #1741] failed in testing BN_sqr openssl in aix 5.2 of 64 bit mode

We did manage to get 0.9.7 building on AIX 64. The necessary patches will be on the request tracker (somewhere). Peter From: Andy Polyakov via RT [EMAIL PROTECTED]

Re: question regarding ./config no-idea no-mdc2 no-rc5

OpenSSL is used just to provide low level crypto. function and for providing crypto. function for API's other than SSL. You don't need to turn off mdc2 now BTW, it was an IBM patent, but it's expired now. Peter

Re: ECDSA

Key generation just uses the lower level EC routines.i.e. EC_KEY_generate_key() EC(DH/DSA) isn't quite the same as DH/DSA. Sorry , I can't help with leaving bits out - there's quite a bit you do need. Peter

Re: [PATCH RFC] Add support to Intel AES-NI instruction set for x86_64 platform

If you want this in the mainstream code, you'll need to detect the capability at runtime and use your alternate code paths only if the hardware is present. It's not even to Intels advantage if OpenSSL crashes and burns on older Intel CPU's and most bulk users of OpenSSL (OS vendors) won't want to

Re: [PATCH RFC] Add support to Intel AES-NI instruction set for x86_64 platform

[attachment signature.asc deleted by Peter Waltenberg/Australia/IBM] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List

Re: [PATCH RFC] Add support to Intel AES-NI instruction set for x86_64 platform

On Thu, 2008-12-11 at 18:04 +0800, Peter Waltenberg wrote: Anything in memory could end up swapped out, but stack is the least likely since it's more often in use, the best you can do is zero the area ASAP. At least

Re: AES-GCM and AES-CCM

IBM submitetd a patch for AES-GCM and AES-CCM some months ago. It's sitting in the request tracker, the later version with Aaron Christensen's acceleration patches and NIST known answer tests is probably the one you want. Merging that into the OpenSSL code base (or not) is up to the OpenSSL

Bug in IBM contributed AES-CCM code

The routine AES_CCM_inc() keeps propagating the carry from an overflow, which means our implementation fails for large blocks of data. The following code fragment should address that bug. /*! @brief Increment the CCM CTR, which is variable length, big endian @param counter the counter to

Re: AES-CCM and -GCM in Release 1.0.0?

I'm working on updating the patch to apply cleanly to the Beta now. Peter From: Paul Suhler paul.suh...@quantum.com

RE: [openssl.org #1935] AES-GCM, AES-CCM, CMAC updated for OpenSSL 1.0 beta 2

, without restriction. -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Peter Waltenberg via RT Sent: Sunday, May 24, 2009 11:55 AM Cc: openssl-dev@openssl.org Subject: [openssl.org #1935] AES-GCM, AES-CCM, CMAC updated for OpenSSL 1.0

Re: [openssl.org #1935] AES-GCM, AES-CCM, CMAC updated for OpenSSL1.0 beta 2

On Mon, May 25, 2009, Peter Waltenberg wrote: Up to the OpenSSL team. I'm happy to do any maintenance required, but it's up to them to merge it - or not. Given that there are a number of people using the patch now and AES

Re: interface stability

Currently the ABI changes depending on compile time options. New functionally ussually means that some struct needs to get new members, and all those structs are public, and applications make direct use of them. And compile time options will add those members. The API for those functions on the

Re: [openssl.org #2046] OpenSSL 1.0.0 beta 3 ASM fails on z/Linux 64-bit

gcc version 4.1.0 (SUSE Linux) tjh:~/work/openssl-1.0.0-beta3 cat /proc/cpuinfo vendor_id : IBM/S390 # processors: 1 bogomips per cpu: 888.01 processor 0: version = FF, identification = 0117C9, machine = 2064 [attachment PGP.sig deleted by Peter Waltenberg/Australia/IBM

Bug in IBM contributed AES-CCM code (large AAD)

I'll post a full patch at some point - but in the interim. This isn't so much a bug as something I forgot to go back and fix when I coded it originally. CCM will fail with AAD 0xff00 bytes as I forgot to add the formatting bytes for the larger AAD's. Note that it still hasn't been tested with

Re: bn_mul_add_words() hangs on my linux-x86_64 built

run make tests in the OpenSSL build tree, or even openssl speed rsa. That'll test the code paths with known good code. If it doesn't hang it's a problem in your code somewhere (try running under valgrind at that point)- if it does hang , you should get better diagnostics from make tests. Peter

Re: [openssl.org #772] 32/64-bit detection on HPUX 11.11

with the code in it is available, but it's too big to post to this list. Peter Peter Waltenberg Team Lead IBM Crypto for C Team IBM/Tivoli Gold Coast Office Phone: +61-7-55524016

Re: [openssl.org #762] Assembler speedups for PPC Linux

at what would be required to support this platform, GCC appears to be the system compiler so I'd be unsurprised if the Linux-PPC code just worked. Peter Peter Waltenberg Team Lead IBM Crypto for C Team IBM/Tivoli Gold Coast Office Phone: +61-7-55524016

Re: bn_lib.c:bn_expand2()

Comment: valgrind on x86 Linux picks up those off-by-one errors quite well if you want an extra screening test. For some reason there was a significant reduction in noise from valgrind in the transition from OpenSSL-0.9.7b-OpenSSL-0.9.7c. Peter Geoff Thorpe [EMAIL PROTECTED] Sent by:

Re: Library cleanup functionality

Potentially useful, but ... A problem we frequently hit is multiple instances of libraries in a single process - often due to applications dragging in shared library dependencies they aren't explicitly aware of. For that reason, this is only mostly safe if you can reference count somehow,

Re: Repost. Assembler Optimizations for PPC hardware.

the other, we have a set of patches we have to apply to the OpenSSL sources before we can build anyway since most of our Linux targets are built with x86 hosted cross-compilers. Peter Peter Waltenberg Architect IBM Crypto for C Team IBM/Tivoli Gold Coast Office Phone: +61-7-55524016

RE: FIPS 140 related patches

on donating that code to OpenSSL anyway - so if you want to go that route, let me know. Peter Peter Peter Waltenberg Architect IBM Crypto for C Team IBM/Tivoli Gold Coast Office Phone: +61-7-55524016 Marquess, Steve Mr JMLFDC [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 25/06/2004 12:31 AM Please

Re: OpenSSL thread safety (was: possibly bug in crypto/rand/rand_win.c)

1. It is safe to create/initialise synchronization objects (ie. a mutex) in DllMain() for DLL_PROCESS_ATTACH. A single master OpenSSL mutex could be created to be used for on-demand (first-access) initialisation of subsystems. I don't recall the equivalent DLL entry point on Unix platforms or

RE: OpenSSL thread safety (was: possibly bug in crypto/rand/rand_win.c)

:[EMAIL PROTECTED] On Behalf Of Peter Waltenberg Sent: Wednesday, 14 July 2004 3:26 PM To: [EMAIL PROTECTED] Subject: Re: OpenSSL thread safety (was: possibly bug in crypto/rand/rand_win.c) 1. It is safe to create/initialise synchronization objects (ie. a mutex) in DllMain() for DLL_PROCESS_ATTACH

Re: Large difference in exported symbols between Windows DLL and Linux shared builds

care if they aren't on Linux and are on some other platform. If you do want to clean it up though, I can probably build for you on any platforms we have that you don't. Peter Peter Waltenberg Architect IBM Crypto for C Team IBM/Tivoli Gold Coast Office Phone: +61-7-55524016 Steven Reddie

Re: AIX 64-bit build.

Peter Waltenberg Andy Polyakov [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 31/05/2005 09:17 PM Please respond to openssl-dev To openssl-dev@openssl.org cc Subject Re: AIX 64-bit build. I have built a 64-bit version of OpenSSL on AIX 5, and it is failing the test

Re: PRNG not seeded on 0.9.8

[EMAIL PROTECTED]:rand diff rand_unix.c~ rand_unix.c 156c156 static const char *randomfiles[] = { DEVRANDOM }; --- static const char *randomfiles[] = { DEVRANDOM }; Peter Waltenberg GOTOU Yuuzou [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 17/06/2005 05:21 PM Please respond

Re: Considering SSL and Cryto libraries for LSB

IBM has already done this in creating it's FIPS certified crypto. code which is layered on top of OpenSSL. In our case we can guarantee that IBM code only uses our restricted subset of the OpenSSL API. Unfortunately you'll need to support the older API's to support legacy applications and in

RE: Safety of using OpenSSL from multiple components in the one process

. Our problems have been more with conflicts with other instances of OpenSSL in customer products. IBM libraries are used by customers who integrate them with their code as well. Peter Peter Waltenberg Steven Reddie [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 03/08/2005 10:26 PM Please

RE: Safety of using OpenSSL from multiple components in the one process

to take extra care to avoid changes which break the ABI between releases. We'd also be happy to contribute code and effort, but as you've pointed out, the core team will have to want these changes made. Peter Peter Waltenberg Steven Reddie [EMAIL PROTECTED] 04/08/2005 09:01 AM To Peter

Re: Proposed new function to allocate EVP_CIPHER_CTX

EVP_CIPHER_CTX *EVP_CIPHER_CTX_new(void) would be more consistant with OpenSSL usage elsewhere, and you should also add an EVP_CIPHER_CTX_free(EVP_CIPHER_CTX *ctx); to free the allocated structure. Since this change is one of the set needed to make the OpenSSL API independent of the underlying

Re: [openssl.org #1272] Problem with config 64 bits AIX 5.2

the exact problem is, but I've done this a number of times myself. Peter Peter Waltenberg B via RT [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 20/01/2006 11:33 PM Please respond to openssl-dev To cc openssl-dev@openssl.org Subject [openssl.org #1272] Problem with config 64 bits AIX

Re: OpenSSL and LSB

ended up in the same process - for LSB you may not need that since the objective is to have everyone use one common version. Cheers Peter Peter Waltenberg Camp, TracyX E

RE: OpenSSL breaks with gcc 4.2

compiler - whether or not the compiler is passing the arguments via the stack or in registers. Peter Peter Waltenberg David Schwartz [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 09/11/2006 06:47 AM Please respond to openssl-dev To openssl-dev@openssl.org cc Subject RE: OpenSSL

RE: OpenSSL breaks with gcc 4.2

Length is not the issue. There is no rule that says that two types must be passed the same way just because they're the same length. For example, some platforms may pass a 64-bit floating point number in a floating point register but pass a 64-bit integer in an integer register. I'm not sure

Re: [openssl.org #2177] New CFB block length breaks old encrypted data

- but it was at least functional for all the awkwardness. Peter Waltenberg From: Kurt Roeckx via RT r...@openssl.org

RE: libcrypto safe for library use?

Historically I suspect the reason there were no default callbacks is that a sizeable proportion of OpenSSL users didn't use threading at all, and the baggage hauling in the thread libraries imposed was significant. I don't think that's an issue anymore - threading is the common case now. But -

Re: libcrypto safe for library use?

for multiple users in the same process to do that at present - all I'm suggesting is that you fix this in the same way the memory callback use is made safe. Peter On Mon, Mar 29, 2010 at 12:03 AM, Peter Waltenberg pwal...@au1.ibm.com wrote: I don't think that's an issue anymore - threading

Re: libcrypto safe for library use?

be 'counted' individually (lock, dynlock, threadid). That would fix this scenario: On Mon, Mar 29, 2010 at 2:02 AM, Peter Waltenberg pwal...@au1.ibm.com wrote: You can't push and pop the callbacks. The software is running in multiple threads and being used by multiple independently developed

RE: libcrypto safe for library use?

Which is essentially what we did at IBM to resolve this - but - closed ecosystem. It was a lot easier. What you could do Provide system default callbacks, allow them to be overridden at most once ONLY if it's done before OpenSSL is usable - i.e. before any OpenSSL_add_all_algorithms() type

Re: Symmetric algorithms with Cell architecture

Waltenberg/Australia/IBM] [attachment PGP.sig deleted by Peter Waltenberg/Australia/IBM] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org

Re: [openssl.org #2232] OpenSSL 1.0.0 - Mac OS X Univesal Binary Build Link errors

Either build with no-asm (and throw away a lot of performance), or build it multiple times and glue the results together with lipo. Peter From: Yvan BARTHÉLEMY via RT r...@openssl.org

RE: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

that as a config time option and most of these problems go away. Anyone with a really unusual configuration can build and ship their own OpenSSL libraries without the default thread support built in and provide their own callbacks - as they presumably do now. Peter Peter Waltenberg Architect IBM Crypto

Re: NIST SP 800-90 recommended RNGs

The OpenSSL team has FIPS compliant SP800-90 PRNG code already. The SP800-90 PRNG's are fairly greedy however so a re-write of the seed source is probably needed as well - and that's a tough problem. Peter

Re: EC curve names

The only good way I found was to use the defined OID's - something like this - no guarantees this table is correct, you should check it. const char *NIST_by_OID[] = { 1.2.840.10045.3.1.1, /* P-192 */ 1.3.132.0.33,/* P-224 */ 1.2.840.10045.3.1.7, /* P-256 */ 1.3.132.0.34,/*

Re: [CVS] OpenSSL: openssl/ CHANGES openssl/crypto/ecdsa/ ecs_ossl.c

FWIW: This isn't like RSA blinding where the impact was significant.The performance impact of this is negligible, it may as well be unconditional. Peter-owner-openssl-...@openssl.org wrote: -To: openssl-dev@openssl.orgFrom: Mounir IDRASSI mounir.idra...@idrix.netSent by:

Re: Reseed testing in the FIPS DRBG implementation

That interpretation seems - brain dead - to be polite.The problem is that running the health check trashes the state of the DRBG you are using, so running it on every reseed means that the DRBG is re-initialized each time - and you may as well be in PR mode anyway. O.K. you could save and restore

Re: [openssl.org #2627] SPARC T4 support for OpenSSL

There are some fairly severe performance hits in engine support unless the engine includes all the submodes as well.That includes things you are just starting to play with now, like the combined AES+SHA1 on x86.For features that are part of CPU's - rather than plug in cards - my preference would

Re: [openssl.org #2627] SPARC T4 support for OpenSSL

05:00 Subject:Re: [openssl.org #2627] SPARC T4 support for OpenSSL Sent by:owner-openssl-...@openssl.org Peter Waltenberg wrote: There are some fairly severe performance hits in engine support unless the engine includes all the submodes as well. That includes things you

Re: OS-independent entropy source?

We've been using this general design on multi-user CPU's for a few years. I'm happier with it there because even if the entropy source is just a hardware PRNG there's enough other noise (bus stalls from other running processes, interrupts etc) to ensure that it's going to be very very difficult

Re: OS-independent entropy source?

Depends on the PLL design - which we don't know. But yes, generally they are notoriously sensitive to thermal effects. I think my point is valid though - even if it is a PRNG, provided it's a good one (and distribution will tell you that) if an attacker can't tell exactly when you are sampling

Re: OS-independent entropy source?

23:55, Peter Waltenberg wrote: I think my point is valid though - even if it is a PRNG, provided it's a good one (and distribution will tell you that) if an attacker can't tell exactly when you are sampling the PRNG effectively it's a usable entropy source. One of the problems is for example

Re: OS-independent entropy source?

No. For following reason. Originally idea was to attempt to gather OS noise. I mean entropy would come from interrupts, interaction with say DMA, etc. Therefore no explicit attempts to perform the experiment outside OS were made. Besides it would be impossible for me to set it up in most cases

Re: OS-independent entropy source?

HT processors are a nightmare for security yes :). You are assuming the target software is collecting data continuously as fast as it can - which I agree, simply turns it into the designated victim :). Don't do that - the data rate it high enough you can sample on demand and you can afford some

Re: OS-independent entropy source?

Well, if you had say a single thread collecting data to feed an entropy pool, once an attacker syncronized on that, they'd win. Not sure that's possible, but it's probably better for security if this is done inline by each thread as needed. (Particularly when you consider the real OpenSSL usage

Re: How encrypt long string RSA

Traditionally, you handle this by encrypting a fixed length symetric key using RSA (i.e. an AES key) and use that key to encrypt any serious amounts of data. Peter From: Frater fr...@poczta.fm To: openssl-dev@openssl.org Date: 27/03/2012 19:53 Subject:How encrypt long string

Re: ppc32_asm for BSD targets

Not a definitive answer, but I know we (IBM) never tested the PPC asm on BSD. It's possible that because no one had a PPC machine running BSD to test the asm paths they were left disabled. There may be other reasons, but make tests should at least show any gross problems.The only subtle problem I

DLL naming

The "easy" fix is to relink the objects yourself.i.e. use the OpenSSL build process to generate everything, ignore it's generated libraries and simply create what you want from the objects that now exist. That way you have almost complete control and it doesn't require changes to the OpenSSL

Encrypt/Decrypt in place ?

Can the same pointer safely be used for the input and output buffers in encrypt and decrypt operations ? i.e. is something like AES_encrypt(out,out,key) guaranteed not to rewrite the input before it's been processed ? The following IMPLIES this is safe but lingering doubts remain. (from

Re: RC4 - asm or C?

Quite a simple answer. The maximum TLS record size is 16k - overhead. Optimize for that (16k). Yes but ... The other cases don't matter, as the packet size decreases, other factors, like TCP/IP stack and network latency dominate performance - so if you send lots of small packets your net

Re: MD5 in openSSL internals

Your answers lie here:http://tools.ietf.org/html/rfc2246The RFC for TLS 1.0OpenSSL implements that, as per specification. And incidentally, as rfc2246 pre-dates (Jan 1999) SHA-256 (2001) the answers aren't the ones you want to hear.NOT an OpenSSL problem that, simply the fact that time has passed

Re: AES-XTS mode doesn't chain between successive calls to EVP_CipherUpdate?

The OpenSSL implementation passes the NIST XTS compliance tests ?XTS was designed to do in-place encryption of blocks of data. (disk encryption etc).Feature rather than bug ?Pete-owner-openssl-...@openssl.org wrote: -To: "openssl-dev@openssl.org" openssl-dev@openssl.orgFrom: "Greg Bryant

Re: [PATCH] libssl: Hide library private symbols

Doing this at link time is far easier and can cover all the OS's. Static doesn't work for symbols that are called inter-module but which shouldn't be in the public API and GCC specific constructs only work for - well, GCC. libeay.num and ssleay.num already list all the public symbols. Parse those

Re: [PATCH] libssl: Hide library private symbols

: Hide library private symbols Sent by:owner-openssl-...@openssl.org El 25/07/13 21:46, Peter Waltenberg escribió: Doing this at link time is far easier and can cover all the OS's. Yes, but this is the worst possible way, as the compiler cannot perform optimizations as it does not know

Re: Self-initialization of locking/threadid callbacks and auto-detection of features

 The simplest fix involves setting the default only once, as wih the callbacks, but here I feel that's a shaky idea, that I should allow RAND method changes at any time, in a thread-safe manner -- more work for me, but less surprising. There is no 'safe' way to do this other than hardwired.

Re: Self-initialization of locking/threadid callbacks and auto-detection of features

at 08:32:35AM +1000, Peter Waltenberg wrote: There is no 'safe' way to do this other than hardwired. Admitted, we have a fairly ugly stack on which to find that out, multiple independently developed lumps of code jammed into the same process, quite a few using dlopen()/dlclose() on other

Re: [openssl.org #3202] Request to remove _sparcv9_random

FWIW. We have a similar problem on AIX with the capability probes there. The debugger has an 'ignore' option - which allows us to bypass the sigill traps.I can understand the logic of not probing for an instruction that'll never exist, but some archictectures you WILL hit this problem as there's

Re: [PATCH] Reseed PRNG on PID change

...@chronox.de To: openssl-dev@openssl.org, Date: 16/01/2014 07:45 Subject:Re: [PATCH] Reseed PRNG on PID change Sent by:owner-openssl-...@openssl.org Am Donnerstag, 16. Januar 2014, 07:41:21 schrieb Peter Waltenberg: Hi Peter, You have access to high speed event counters on most

Re: Define a method to rename dynamic libraries [patch]

only for the named recipient. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action based on the contents of this information is strictly prohibited. [attachment RenameDLLs.patch deleted by Peter Waltenberg/Australia/IBM

Re: SHA-3 availability

Personally I'd advise against this until NIST publishes test vectors for the finalist.We already have:DES(_OLD) and DES.SHA0 and SHA1Rjindael and AES.NIST has a long track record of changing algorithms before going 'final' and the problem is that once people start using the 'bad' version of the

Re: heartbeat RFC 6520 and silently drop behaviour

Not a good idea, particularly with DTLS as it'd be an instant DOS attack.Peter-owner-openssl-...@openssl.org wrote: -To: openssl-dev@openssl.orgFrom: David Jacobson Sent by: owner-openssl-...@openssl.orgDate: 04/14/2014 07:55PMSubject: Re: heartbeat RFC 6520 and

Re: AW: [openssl.org #3312] OpenSSL :: crypto/mem.c without memset() calls?

In fact, it doesn't. The memset() function called has to be unknown to the compiler (i.e. not builtin) and in another module, but even there, the linker could optimize it out. And yes, there have been linkers 'capable' of optimizing that call out. Personally, I blame OS/2 for most of these

Re: Upgrading OpenSSL on RHEL5

I stumbled across this a few days ago. Which will at least tell you if the OS openssl package was patched on RedHat based systems. rpm -q --changelog openssl or to save time rpm -q --changelog openssl | grep CVE Peter From: Paul Vander Griend paul.vandergri...@gmail.com To:

Re: Prime generation

Not quite correct, the prime rands shouldn't come from a DRBG, they should come from an NRBG (NIST terminology). There's a considerable difference between the performance of an entropy source and a DRBG. The output of a DRBG not being non-deterministic being the important point. /dev/random V

Re: Prime generation

: Joseph Birr-Pixton <jpix...@gmail.com> Sent by: owner-openssl-...@openssl.orgDate: 05/27/2014 07:14PM Subject: Re: Prime generation On 27 May 2014 08:45, Peter Waltenberg pwal...@au1.ibm.com wrote: ... I did change the RNG sources for some of the OpenSSL code in our hacked version t

  1   2   >