From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 border1.nntp.dca1.giganews.com!nntp.giganews.com!news.glorb.com!enother.net!enother.net!peer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!fx09.iad.POSTED!not-for-mail
From: Brad Moore <brad.moore@shaw.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Should Ada runtime provide special primitives for cryptography?
References: <slrnm2nfj4.nrc.lithiumcat@nat.rebma.instinctive.eu>
 <npvn2a9cdq2habaut03s7bho39grrr42h5@4ax.com>
In-Reply-To: <npvn2a9cdq2habaut03s7bho39grrr42h5@4ax.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <2UUWv.310935$Fo3.68916@fx09.iad>
NNTP-Posting-Host: 68.145.219.148
X-Complaints-To: internet.abuse@sjrb.ca
X-Trace: 1412176510 68.145.219.148 (Wed, 01 Oct 2014 15:15:10 UTC)
NNTP-Posting-Date: Wed, 01 Oct 2014 15:15:10 UTC
Date: Wed, 01 Oct 2014 09:15:02 -0600
X-Received-Bytes: 2205
X-Received-Body-CRC: 429193226
Xref: number.nntp.giganews.com comp.lang.ada:189281
Date: 2014-10-01T09:15:02-06:00
List-Id: <comp.lang.ada>

On 14-10-01 07:22 AM, Dennis Lee Bieber wrote:
> On Wed, 1 Oct 2014 08:42:17 +0000 (UTC), Natasha Kerensikova
> <lithiumcat@instinctive.eu> declaimed the following:
>
>> However, when actually implementing cryptographic stuff, cleverness from
>> compiler and optimizer are often enemies. For example, overwriting a
>> buffer with zeroes might be optimized out when the buffer is not
>> accessed again.
>>
> 	Cryptographic "zeroing" does not fill a buffer with 0x00 values. One
> approved method is to:
>
> generate random sequence (in a second buffer as you'll need it again)
> copy random sequence into crypto buffer
> compare buffers to ensure data was changed
> invert the bits of the random sequence
> copy random sequence into crypto buffer
> compare to ensure all data changed
> generate second random sequence
> copy second sequence into buffer
> compare buffers
>
> The first two copy operations ensure every bit in the buffer has been
> toggled to both states -- the compares ensure you don't have a "sticky
> bit".

>

Zeroizing can be useful as well. For example, a system might zeroize its 
data to ensure critical, possibly encrypted data cannot be accessed 
after the data has been processed, or before exposing the data to an 
environment where it could be accessed.