Re: [openssl-dev] evp cipher/digest - add alternative to init-update-final interface

Or just add another EVP_CIPHER_CTX_ctrl() option (EVP_CTRL_CIPHER_ONE_SHOT or similar.) and handle it the way CCM does now and finish the operation on the first data update. That doesn't require a new API and would probably simplify some existing code. Peter From: Patrick Steuer

Re: [openssl-dev] Work on a new RNG for OpenSSL

The bad case I'm aware of is the fork() one as it's critical that the RNG state diverge on fork(). Without that you can get some very nasty behaviour in things like TLS servers. Some of which have a thread pool + fork() model to handle increasing load. While ideally you'd do a complete reseed,

Re: [openssl-dev] Work on a new RNG for OpenSSL

Re: [openssl-dev] Work on a new RNG for OpenSSL Sent by:"openssl-dev" <openssl-dev-boun...@openssl.org> > On 28 Jun 2017, at 04:00, Paul Dale <paul.d...@oracle.com> wrote: > > > Peter Waltenberg wrote: >> The next question you should be asking is: d

Re: [openssl-dev] Work on a new RNG for OpenSSL

t:Re: [openssl-dev] Work on a new RNG for OpenSSL Sent by:"openssl-dev" <openssl-dev-boun...@openssl.org> On 06/27/2017 06:41 PM, Peter Waltenberg wrote: > Consider most of the worlds compute is now done on VM's where images are > cloned, duplicated and

Re: [openssl-dev] Work on a new RNG for OpenSSL

The next question you should be asking is: does our proposed design mitigate known issues ?. For example this: http://www.pcworld.com/article/2886432/tens-of-thousands-of-home-routers-at-risk-with-duplicate-ssh-keys.html Consider most of the worlds compute is now done on VM's where images are

Re: [openssl-dev] License change agreement

OpenSSL has a LOT of commercial users and contributors. Apache2 they can live with, GPL not so much. There's also the point that many of the big consumers (like Apache :)) are also under Apache2. Least possible breakage and I think it's a reasonable compromise. Of course I am biased because I

Re: [openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production release

Just commenting on this: I had very few problems moving from 1.0.2 to 1.1.0. We'd already cleaned up most of the issues OpenSSL fixed between 1.0.2 and 1.1.0, those fixups were well isolated so migrating was just a matter of ifdef'ing out accessors/allocators/deallocators we'd created to civilize

Re: [openssl-dev] MD5 speed

No one cares ?.I'd suggest you check for alignment issues first as that tends to dominate at small block sizes.The no one cares is only partly in jest as MD5 is dead, but not yet buried. And in the grand scheme of things even a 2:1 performance hit on 16 byte blocks is unlikely to change the

Re: [openssl-dev] [EXTERNAL] Re: use SIPhash for OPENSSL_LH_strhash?

oding attack could be used againstOpenSSL's hash tables, and it sounds like there isn't. In that case,the fastest algorithm for the usage patterns would be best.Regards,                          jjfOn 11/01/2017 22:25, Peter Waltenberg wrote: And the reason I said you certainly don't n

Re: [openssl-dev] use SIPhash for OPENSSL_LH_strhash?

patterns would be best.Regards,       jjfOn 11/01/2017 22:25, Peter Waltenberg wrote:And the reason I said you certainly don't need a keyed hash ?Behaviour of the hash function will change with ke

Re: [openssl-dev] use SIPhash for OPENSSL_LH_strhash?

And the reason I said you certainly don't need a keyed hash ? Behaviour of the hash function will change with key and in some cases performance would degenerate to that of a linked list. (Ouch). And since the obvious thing to do is use a random key, OpenSSL's performance would get *very*

Re: [openssl-dev] use SIPhash for OPENSSL_LH_strhash?

Reality check Others have pointed this out but I don't think it's making it through. LHash doesn't need a cryptographic hash and it doesn't have security implications. It certainly doesn't need a keyed hash. LHash does need to be something that's good at distinguishing short text strings,

Re: [openssl-dev] Add a new algorithm in "crypto" dir, how to add the source code into the build system

It's changed in recent OpenSSL. 1.1.0c the directories are in Configure. # Top level directories to build $config{dirs} = [ "crypto", "ssl", "engines", "apps", "test", "util", "tools", " fuzz" ]; # crypto/ subdirectories to build $config{sdirs} = [ "objects", "md2", "md4", "md5",

Re: [openssl-dev] Making assembly language optimizations working onCortex-M3

That may not be a good idea. The vast majority of OpenSSL in use isn't targetted at a specific processor variant. It's compiled by an OS vendor and then installed on whatever. IF you are in the situation where you are compiling for a space constrained embedded processor then hopefully your

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

No, you got that right, NULL being 'safe' to free varies with OS. But - you aren't calling free() directly, THIS makes it safe. That's one of the other benefits of having objects allocated and released by internal functions rather than doing it directly. void BN_MONT_CTX_free(BN_MONT_CTX *mont)

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

No, you got that right, NULL being 'safe' to free varies with OS. But - you aren't calling free() directly, THIS makes it safe. That's one of the other benefits of having objects allocated and released by internal functions rather than doing it directly.void BN_MONT_CTX_free(BN_MONT_CTX *mont){   

Re: [openssl-dev] Question about dynamically loadable engines on Cygwin / Mingw

Possibly the best fix is to simply not specify the library prefix or suffix.i.e. -engine capiAnd let OS/build specific code sort out the rest. You still have .so and .sl on different variants of HP/UX for example.Next best, specify the complete library name in all cases - and I'll concede, best

Re: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue...

You can also add some more macros to the perlasm which already translates a LOT of opcodes into something older assemblers won't choke on.Pete-"openssl-dev" wrote: -To: robert.go...@igt.comFrom: Jeremy Farrell via RT Sent by:

Re: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue...

You can also add some more macros to the perlasm which already translates a LOT of opcodes into something older assemblers won't choke on. Pete -"openssl-dev" wrote: -To: robert.go...@igt.com From: Jeremy Farrell via RT Sent by: "openssl-dev" Date:

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

might be good advice for some things, but ussually not when it‎ comes to crypto. Kurt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 Please log in as guest with password guest if

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

might be good advice for some things, but ussually not when it‎ comes to crypto. Kurt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 Please log in as guest with password guest if

Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread

I'd suggest checking where the bottlenecks are before making major structural changes. I'll admit we have made a few changes to the basic OpenSSL sources but I don't see unacceptable amounts of locking even on large machines (100's of processing units) with thousands of threads.Blinding and the

Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread

" Please do. It will make this much safer. Also, you might want to run some experiments to find the best stack size on each platform. The smaller the stack you can get away with, the better. " It does, but it also requires code changes in a few places. probable_prime () in bn_prime.c being

Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread

23, 2015 at 09:53:15PM +1000, Peter Waltenberg wrote: > > " > Please do. It will make this much safer. Also, you might want to run > some experiments to find the best stack size on each platform. The > smaller the stack you can get away with, the better. > " > > It

Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Quite reasonable except. I'm not sure you have majority and minority the right way around. My guess would be that the majority of OpenSSL users are libcrypto. consumers rather than SSL/TLS consumers. A point several of us have been trying to get through for some time. Peter-"openssl-dev"

Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

to from OpenSSL 1.1 - seeking feedback Sent by:"openssl-dev" <openssl-dev-boun...@openssl.org> On Mon, Nov 16, 2015 at 9:06 PM, Peter Waltenberg <pwal...@au1.ibm.com> wrote: Why not offer another set of get_XYZ_byname() which resticts the caller to socially acce

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

The reason for keeping the old crypto. algorithms around is the obvious one, that's been stated over and over. OpenSSL's SSL isn't the only consumer of the algorithms, remove the low level algorithms and you risk breaking more than OpenSSL. SSH, IKE,IPSec, Kerberos and I'm sure there are more,

Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Why not offer another set of get_XYZ_byname() which resticts the caller to socially acceptable algorithms. Or allows the opposite, it really doesn't matter but restricted being the newer API breaks less code by default. Give it the same call syntax and it's simply an #ifdef in the OpenSSL

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

I also can't see any point expunging old algorithms from the sources, making them not build by default should be enough. They are known to work and there's always the issue of 'legacy' support. With the number and variety of consumers OpenSSL has that's likely to be a problem for years to

Re: [openssl-dev] Improving OpenSSL default RNG

If you are going to make all that effort you may as well go for FIPS compliance as the default.SP800-90 A/B/C do cover the areas of concern, the algorithms are simple and clear as is the overall flow of processing to start from 'noise' to produce safe and reliable TRNG/PRNG's. More importantly,

Re: [openssl-dev] [openssl.org #4045] RSA_generate_key()

Depends on the CPU, if you have a slow CPU RSA key gen will be slow. It seems to take ~ 1/10th of a second here with current x86_64 hardware. Something less capable. (ARM7) ~ 5 seconds. Your mips hardware is slow but in the ballpark. Peter From: BeomGeun Bae via RT

Re: [openssl-dev] [openssl.org #3955] [PATCH] Reduce stack usage in PKCS7_verify()

bn/bn_prime.c static int probable_prime(BIGNUM *rnd, int bits) { int i; prime_t mods[NUMPRIMES]; == BN_ULONG delta, maxdelta; This one is also excessive. The problem is that even on OS's with dynamic thread stack if you do cause a stack overrun, the entire process

Re: [openssl-dev] [openssl.org #3955] [PATCH] Reduce stack usage in PKCS7_verify()

bn/bn_prime.c static int probable_prime(BIGNUM *rnd, int bits) { int i; prime_t mods[NUMPRIMES]; == BN_ULONG delta, maxdelta; This one is also excessive. The problem is that even on OS's with dynamic thread stack if you do cause a stack overrun, the entire process

Re: [openssl-dev] sizeof (HMAC_CTX) changes with update, breaks binary compatibility

Which is exactly why our hacked version of OpenSSL has allocators/deallocators for all these private struct's. It'd be really nice if OpenSSL would fix this, adding them won't break backwards compatibility (i.e. API breakage isn't an excuse for not fixing these) and going forwards problems like

Re: Error _armv7_tick openssl

ARM is one of those awkward processors, the event counter isn't always directly readable from userspace, if it's not directly readable you get an illegal instruction trap. A syscall to access the event counters is only present in recent kernels. And even more fun, the event counter data is only

Re: Single-Makefile Build Experiment report

Just a comment. the OpenSSL build already depends on Perl and Perl already has a Make of it's own . That would at least relieve some of the problems with being dependent on lowest common denominator features common to the various platform makes. I'll admit, I have no idea whether the Perl variant

Re: [openssl.org #782] IBM patches to OpenSSL-0.9.7c

That's essentially correct. Any IBM contributions from me have been dealt already, just to save time if you hit more. Thanks Peter From: Rich Salz via RT r...@openssl.org To: Peter Waltenberg/Australia/IBM@IBMAU Cc: openssl-dev@openssl.org Date: 15/08/2014 12:27 PM Subject

Re: Re : Re: [openssl.org #3442] [patch] AES XTS: supporting custom iv from openssl enc command

from openssl enc command On Sat, Jul 12, 2014, Peter Waltenberg wrote: Or extend EVP_CIPHER_CTX_ctrl() to handle things like changing IV's ? Modes like XTS may gain a lot from that, you could use EVP_CIPHER_CTX_copy() to avoid repeated key expansion costs, change the IV with EVP_CIPHER_CTX_ctrl()

Re : Re: [openssl.org #3442] [patch] AES XTS: supporting custom iv from openssl enc command

Or extend EVP_CIPHER_CTX_ctrl() to handle things like changing IV's ? Modes like XTS may gain a lot from that, you could use EVP_CIPHER_CTX_copy() to avoid repeated key expansion costs, change the IV with EVP_CIPHER_CTX_ctrl() and do the next block. Peter-owner-openssl-...@openssl.org wrote:

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

Personally, I have test coverage of the ciphers and hashes we use which deliberately misaligns input and output buffers. I think we picked up one problem, several years ago. O.K. someone COULD use a compiler the OpenSSL team doesn't, but frankly test coverage seems the best option. No risk, no

Re: EVP_CIPHER_CTX_copy() segv with XTS

ggests that the only pointer in there is (*stream) which points to the function which is responsible for doing encryption/decryption and should be safe to copy to the new CTX On Mon, Jun 30, 2014 at 9:42 AM, Peter Waltenberg pwal...@au1.ibm.com wrote: This appears to be the same 'pattern' error as GCM. F

EVP_CIPHER_CTX_copy() segv with XTS

This appears to be the same 'pattern' error as GCM. For XTS ctx- cipher_data contains pointers and the contents are aren't being fully duplicated by the copy. Peter __ OpenSSL Project

RE: [openssl.org #3373] [BUG] [WIN] DLL copyright message not synchronize for quite a while

On the other hand, we try to keep the advertised (c) on binaries up to date. About the only way to do that is to make updating the (c) date part of the build scripts, that's relatively easy on Windows as the resource file is text and gets compiled. Which reminds me ... :{Peter

Re: Locking inefficiency

Please correct me if I'm wrong, but the ERR/OID structures only need locking because they are loaded dynamically ?. Preload them all at startup with a global lock held, delete them at shutdown with a global lock held. If all the other access is 'read' the structures don't need a lock between

Re: Locking inefficiency

It's a thread from a few months ago. OpenSSL needs to establish a default thread model in many cases. The one we (IBM) hit is composite apps. Multiple independently developed lumps of code thrown together - someone has to set the locks, but deciding who is a problem. We deal with it easily as we

RE: patch for make depend, chacha

IMHO, that's a good call. If a 'broken' algorithm gets in, it tends to stay there for a very long time. DES_OLD, SHA0 are examples already in the OpenSSL code base. Something else that could easily be killed now. Pete-owner-openssl-...@openssl.org wrote: - To: "openssl-dev@openssl.org"

Re: AW: Which platforms will be supported in the future on which platforms will be removed?

by:owner-openssl-...@openssl.org On Tue, Jun 03, 2014 at 02:22:07PM +1000, Peter Waltenberg wrote: One of the uglier problems is that unless you can build/test on all the platforms on each change you'll almost certainly break platforms unexpectedly - that lack of hardware has been one

Re: AW: Which platforms will be supported in the future on which platforms will be removed?

The other thing to consider is that perhaps OpenBSD really has the right approach, which is that portability should be done via support libraries, and not part of the core code. That might impact performance on some legacy piece of cr*p, but presumably, impacted performance is better than no

Re: AW: Which platforms will be supported in the future on which platforms will be removed?

...@mit.edu To: openssl-dev@openssl.org Date: 03/06/2014 12:01 PM Subject:Re: AW: Which platforms will be supported in the future on which platforms will be removed? Sent by:owner-openssl-...@openssl.org On Tue, Jun 03, 2014 at 11:22:58AM +1000, Peter Waltenberg

Re: AW: Which platforms will be supported in the future on which platforms will be removed?

:Re: AW: Which platforms will be supported in the future on which platforms will be removed? Sent by:owner-openssl-...@openssl.org On Tue, Jun 03, 2014 at 12:20:17PM +1000, Peter Waltenberg wrote: (c) EBCDIC. z/OS is still alive. I'll concede that one is weird

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

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: 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: 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: 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: 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: [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: [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: 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: 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: [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: 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: 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: 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

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

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

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

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: 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: 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?

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?

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: [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: [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: 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: [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: 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: 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: [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: [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: 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: 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: 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: [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

[openssl.org #2162] Updated CMAC, CCM, GCM code

(See attached file: ibmupdate1.tgz) This is an update to the sources (only) for the CMAC, CCM and GCM code we donated previously. It rolls up various bug fixes for those who need them collected in one place, but isn't a full patch to OpenSSL. Current status. GCM appears solid now with a 96 bit

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

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: [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

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 #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: 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

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

  1   2   >