[Geoff Thorpe <geoff@geoffthorpe.net>: Re: IMPORTANT: The release of 0.9.6h is postponed]

[Jeffrey Altman]

The discussion about what to do about memset() optimizations has
continued in many forums.  The following is where the OpenSSL team
appears to be heading. 

                ---------------

Return-Path: <owner-mmx-openssl-users at mmx.engelschall.com>
Received: from mmx.engelschall.com (mmx.engelschall.com [195.27.130.252])
	by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gANIcSKn029144;
	Sat, 23 Nov 2002 13:38:28 -0500 (EST)
Received: by mmx.engelschall.com (Postfix)
	id DCAE01938B; Sat, 23 Nov 2002 19:38:12 +0100 (CET)
Received: from opensource.ee.ethz.ch (opensource-01.ee.ethz.ch [129.132.7.153])
	by mmx.engelschall.com (Postfix) with ESMTP id 84AA01938A
	for <mmx-openssl-users at mmx.engelschall.com>; Sat, 23 Nov 2002 19:38:12 +0100 (CET)
Received: by en5.engelschall.com (Sendmail 8.9.2) for openssl-users-L
	id TAA10056; Sat, 23 Nov 2002 19:37:11 +0100 (MET)
Received: by en5.engelschall.com (Sendmail 8.9.2) via ESMTP for <openssl-users at openssl.org>
	from VL-MS-MR002.sc1.videotron.ca id TAA10052; Sat, 23 Nov 2002 19:36:45 +0100 (MET)
Received: from dopey.geoffnet ([24.202.164.168])
 by VL-MS-MR002.sc1.videotron.ca
 (iPlanet Messaging Server 5.2 HotFix 0.9 (built Jul 29 2002))
 with ESMTP id <0H61009G6L17G2 at VL-MS-MR002.sc1.videotron.ca> for
 openssl-users at openssl.org; Sat, 23 Nov 2002 13:36:44 -0500 (EST)
Date: Sat, 23 Nov 2002 13:36:43 -0500
From: Geoff Thorpe <geoff at geoffthorpe.net>
Subject: Re: IMPORTANT: The release of 0.9.6h is postponed
In-reply-to: <Pine.LNX.4.44L0.0211230810550.14157-100000 at smtp.datapower.com>
To: openssl-users at openssl.org
Message-id: <200211231336.43269.geoff at geoffthorpe.net>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
User-Agent: KMail/1.4.3
References: <Pine.LNX.4.44L0.0211230810550.14157-100000 at smtp.datapower.com>
Sender: owner-openssl-users at openssl.org
Precedence: bulk
Reply-To: openssl-users at openssl.org
X-Sender: Geoff Thorpe <geoff at geoffthorpe.net>
X-List-Manager: OpenSSL Majordomo [version 1.94.4]
X-List-Name: openssl-users

On November 23, 2002 08:11 am, Rich Salz wrote:
> The above cannot be optimized out, and forces the memset calls to not
> be optimized out.

IMHO this is all getting a bit overly complicated and academic. ANSI/ISO 
pedantics aside, this issue seems to raise a simple conclusion - memset() 
is not how you sanitise memory if you intend it not to be vulnerable to 
scanning attacks.

But then we already knew that - Peter Gutmann had pointed out in the past 
that a single write of zeroes to disk or memory doesn't protect against 
the previous values being retrieved if you have physical (power-off) 
access. So aggressive compilers are simply forcing an issue we should 
have confronted anyway - clean the memory properly.

Eg.
    CRYPTO_cleanse(void *ptr, size_t len)
    {
        static unsigned char foo = 0;
        unsigned char *p = ptr;
        size_t loop = len;
        while(loop--) {
            *(p++) = foo++;
            foo += (17 + (unsigned char)(p & 0xF))
        }
        if(memchr(ptr, foo, len))
            foo += 63;
    }

It becomes like a semi-PRNG in some ways which IMHO is better than 
zeroing. By mixing in the pointer's lower-byte in I can't see that a 
compiler would be able to generalise the loop, and with the memchr() at 
the end feeding back to the state I think the combination would force the 
compiler to honour the memory-writes.

Thoughts?

Cheers,
Geoff

-- 
Geoff Thorpe
geoff at geoffthorpe.net
http://www.geoffthorpe.net/


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users at openssl.org
Automated List Manager                           majordomo at openssl.org


 Jeffrey Altman * Volunteer Developer      Kermit 95 2.1 GUI available now!!!
 The Kermit Project @ Columbia University  SSH, Secure Telnet, Secure FTP, HTTP
 http://www.kermit-project.org/            Secured with MIT Kerberos, SRP, and 
 kermit-support at columbia.edu               OpenSSL.