Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

It's also not that much of a problem in practice.. If you are using those API's you are adding new crypto. methods. Doing that after threading has started is not going to give good results with or without locking. Peter From: "Salz, Rich via openssl-dev" To: "openssl-dev@openssl.org"

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

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" > On 28 Jun 2017, at 04:00, Paul Dale wrote: > > > Peter Waltenberg wrote: >> The next question you should be asking is: does our proposed design mitigate known issues ?. >> F

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

rk on a new RNG for OpenSSL Sent by:"openssl-dev" 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 restarted as a matter of course. Not vastly > different from an embedd

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 work

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

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

27;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 need a keyed hash ?Behaviour

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

ng to consider is whether or not there is any practical way a hash flooding attack could be used against OpenSSL's hash tables, and it sounds like there isn't. In that case, the fastest algorithm for the usage patterns would be best.Regards,    

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

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

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", "sha",

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 engine

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 an

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: "openssl-dev" Date: 02/13/2016

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: 02/13/2016 03:46AM Cc: openssl-dev@ope

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

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 prompted [attachment &quo

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

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 prompted [attachment &quo

Re: [openssl-dev] Backporting opaque struct getter/setter functions

The point of using accessor FUNCTIONS is that the code doesn't break if the structure size or offsets of fields in the underlying structures change across binaries.Where that mainly has an impact is updating the crypto/ssl libs underneath existing binaries is more likely to just work.#defines in t

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 RN

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

e ends up in the same process. Peter From: Nico Williams To: openssl-dev@openssl.org Date: 24/11/2015 10:42 Subject:Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread Sent by:"openssl-dev" On Mon, Nov 23, 2015 at

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 far

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

om OpenSSL 1.1 - seeking feedback Sent by: "openssl-dev" On Mon, Nov 16, 2015 at 9:06 PM, Peter Waltenberg wrote: 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 matte

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 heade

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

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 come.The

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

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 To: Cc: openssl-

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 ge

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 ge

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 r

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" To: Peter Waltenberg/Australia/IBM@IBMAU Cc: openssl-dev@openssl.org Date: 15/08/2014 12:27 PM Subject:

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 vari

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

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

Re: EVP_CIPHER_CTX_copy() segv with XTS

r are just commenting on the previous GCM fix? A quick look at the EVP_AES_XTS_CTX suggests 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 W

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 http://w

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

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 times

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 p

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

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

he future on which platforms will be removed? Sent 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 certa

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

Ts'o" To: openssl-dev@openssl.org Date: 03/06/2014 12:55 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 12:20:17PM +1000, Peter Walte

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

7;live' platform. Peter From: "Theodore Ts'o" 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.o

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 sup

Re: Prime generation

wrote: - To: openssl-dev@openssl.orgFrom: Joseph Birr-Pixton Sent by: owner-openssl-...@openssl.orgDate: 05/27/2014 07:14PM Subject: Re: Prime generation On 27 May 2014 08:45, Peter Waltenberg wrote: > ...> I did change the RNG sources for some of the OpenSSL code in our hacked > v

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

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 To: openssl-dev@openssl.org Date: 24/04

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 problem

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 silently drop behaviourOn 4/

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 alg

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

y 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 "RenameDLL

Re: [PATCH] Reseed PRNG on PID change

ter From: Stephan Mueller 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 spee

Re: [PATCH] Reseed PRNG on PID change

You have access to high speed event counters on most platforms now. Where those are available, use them for reseed data instead of gettimeofday(). Far higher resolution, far less performance impact. Peter From: "Dr. Stephen Henson" To: openssl-dev@openssl.org, Date: 16/01/2014 02:50

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 no

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

23, 2013 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, qui

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

Re: [PATCH] libssl: Hide library private symbols

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

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: 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" From: "Greg Bryant (grbryant)" Sent by: own

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 throug

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 crypto/ae

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 build

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 To: openssl-dev@openssl.org Date: 27/03/2012 19:53 Subject:How encrypt long string RSA Sent by:

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 sce

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 del

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 cas

Re: OS-independent entropy source?

Sent by:owner-openssl-...@openssl.org On 17.01.2012 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

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 the

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 f

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

te: 08/11/2011 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 i

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 be

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 Sent by: owner-openssl-...@openssl.orgDate: 05/28/20

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

eds to do is provide 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 Walten

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

We hit the same problem with IBM code. You simply can't resolve this "externally" when you have multiple shared libraries that were built independently stuffed into the same process - and in our case most of those libs were originally applications in their own right (so think they are "god" anyway

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"

Re: Symmetric algorithms with Cell architecture

l.org Is there anyone working with symmetric algorithms in Cell platform, i want suggestions to work with AES, taking advantage of the IBM Cell SPUs Thanks in advance[attachment "smime.p7s" deleted by Peter Waltenberg/Australia/IBM] [atta

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?

" I don't think you can avoid a dependency on the system threading library though, but I don't see why that would be an issue. Many single-threaded programs wind up requiring the threading library on many platforms anyway as it may contain functions like 'clock_gettime' or 'sched_yield'. (Does anyo

Re: libcrypto safe for library use?

tdown invocations and only really act on the first one. And setting up the callbacks counts as individual pieces of init code, so they might be 'counted' individually (lock, dynlock, threadid). That would fix this scenario: On Mon, Mar 29, 2010 at 2:02 AM, Peter Waltenberg wrote: You

Re: libcrypto safe for library use?

ks - they must be set, but there's no safe way 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 Waltenber

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

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

he past - but it was at least functional for all the awkwardness. Peter Waltenberg From:

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

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

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 AAD

Re: ECDSA_do_verify()

FYI. OpenSSL 0.9.8e 23 Feb 2007 built on: Fri Oct 16 14:31:12 EST 2009 platform: linu x-x86_64 compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_ DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int -DOPENS SL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_AS

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

ation at some point. Note that this code does only compile for a 64 bit target. It doesn't work with 32 bit code. Peter

  1   2   >