[cryptography] Just how bad is OpenSSL ?

Solar Designer solar at openwall.com
Sun Oct 28 15:01:23 EDT 2012


On Sat, Oct 27, 2012 at 06:47:05PM -0700, Patrick Pelletier wrote:
> For the most part, I would say that OpenSSL is not badly written, just 
> badly documented.  I am not a cryptography expert (just a smart, 
> experienced programmer, trying to use TLS) so I'm not in a particularly 
> good position to judge the cryptographic merits of OpenSSL.  For the 
> most part, it seems sound, although a couple of things have given me 
> pause.  One is OPENSSL_cleanse, which overwrites memory with random 
> data.  Every other cryptography library I've seen seems to be happy with 
> just overwriting sensitive memory with zero.  I haven't seen any 
> explanation of why OpenSSL believes that overwriting with random data is 
> better than overwriting with zero.  In the absence of an explanation, it 
> feels a bit cargo-cultish.

There is explanation.  CHANGES:

  *) New function OPENSSL_cleanse(), which is used to cleanse a section of
     memory from it's contents.  This is done with a counter that will
     place alternating values in each byte.  This can be used to solve
     two issues: 1) the removal of calls to memset() by highly optimizing
     compilers, and 2) cleansing with other values than 0, since those can
     be read through on certain media, for example a swap space on disk.
     [Geoff Thorpe]

crypto/mem.c (two places):

	/* Create a dependency on the value of 'cleanse_ctr' so our memory
	 * sanitisation function can't be optimised out. NB: We only do
	 * this for >2Kb so the overhead doesn't bother us. */
	if(ret && (num > 2048))
	{       extern unsigned char cleanse_ctr;
		((unsigned char *)ret)[0] = cleanse_ctr;
	}

The OPENSSL_cleanse() function is such that the memory is overwritten
with the counter values, whereas the counter is incremented in ways
dependent on the pointer to the memory region, and it is used to
"pre-initialize" regions being allocated by OpenSSL's CRYPTO_malloc().
This creates a non-trivial inter-dependency between the memory allocator
and the memory sanitization functions, which presumably a compiler won't
recognize as something that can be optimized out with no effect on
operation of correctly written programs.

Frankly, I do find this specific approach questionable, but the
rationale is there, and the compiler optimization problem that this
weird approach is trying to solve is real.

Alexander



More information about the cryptography mailing list