[cryptography] Just how bad is OpenSSL ?

Jeffrey Walton noloader at gmail.com
Mon Oct 29 19:47:29 EDT 2012

Hi Alexander,

Sorry to go offlist.

On Mon, Oct 29, 2012 at 7:31 PM, Solar Designer <solar at openwall.com> wrote:
> On Mon, Oct 29, 2012 at 04:06:58PM -0400, Jeffrey Walton wrote:
>> On Sun, Oct 28, 2012 at 3:01 PM, Solar Designer <solar at openwall.com> wrote:

>> GCC uses volatile strictly for memory mapped hardware
>> (http://gcc.gnu.org/ml/gcc-help/2012-03/msg00251.html), so its an
>> abuse that the value is changed by software.
> <offtopic>
> This thread on gcc-help talks about two possible uses of volatile: for
> memory-mapped I/O (correct) and for communication between threads (wrong
> unless memory barriers are also used).  However, these are not the only
> possible uses.  volatile is also useful for communication within one
> process (one thread), typically when the main program wants to check
> whether one of its signal handlers has been called.  The signal handler
> updates a variable and returns.  The main program reads the volatile
> variable from inside a loop and becomes aware of the event.  Without the
> volatile keyword, it would potentially be reading a cached copy of the
> variable (usually a register), so it would not learn of the event until
> much later (likely until exiting/re-entering the function), if at all.
> </offtopic>
According to GCC's interpretation, I believe this is an abuse since
volatile only applies to memory mapped hardware.

>> The OpenSSL cleanse() function will likely fail on BIOs created from
>> storage and memory mapped files when used on SSDs due to write
>> leveling and on-controller compression. If write leveling goes away,
>> it looks like cleanse() will still fail due to compression. Hence the
>> need for random, non-compressible data.
> Not overwriting the same location may also happen due to journaling
> filesystems.
This is a tough problem, and I have not figured out how to solve it
short of using an encrypted drive (not available on all hardware, such
as Mac Books). Risk Acceptance to the rescue!


More information about the cryptography mailing list