Re: Should Ada runtime provide special primitives for cryptography?

[Dennis Lee Bieber <wlfraed@ix.netcom.com>]

On Wed, 01 Oct 2014 09:15:02 -0600, Brad Moore <brad.moore@shaw.ca>
declaimed the following:

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

	The problem is that, in a really paranoid environment, just writing
zeroes is NOT considered sufficient; there may be subtle traces that
special hardware could pull out. Especially if the data ever hit magnetic
media -- a single write of zeroes on a drive platter, say, may only flatten
the previous data enough that the drive reports it as zeroes, but passing
the head signal to an oscilloscope (for example) might still show ripples
of underlying residual magnetism. The three pass scheme I described ensures
at least two state changes are imposed on those residuals, along with
leaving a random mess as the third pass.

http://csrc.nist.gov/publications/drafts/800-88-rev1/sp800_88_r1_draft.pdf


	Okay -- I'm apparently working from decade old practice (2001 was about
the time I had to be concerned with clearing encryption keys from a laptop
used to load keys into a PPS-rated GPS receiver).

http://cascadeam.typepad.com/it_asset_retirement_value/2012/10/debunking-the-3-pass-overwrite-requirement.html

	OTOH: if the data hits a flash memory device -- grinding up the memory
is the only approved method, since the device may do "wear leveling" which
means the attempt to overwrite the data actually gets written to some other
location on the device (to equalize writes to the media).

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/