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: Xl.tags.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail NNTP-Posting-Date: Wed, 01 Oct 2014 21:13:17 -0500 From: Dennis Lee Bieber Newsgroups: comp.lang.ada Subject: Re: Should Ada runtime provide special primitives for cryptography? Date: Wed, 01 Oct 2014 22:13:26 -0400 Organization: IISS Elusive Unicorn Message-ID: References: <2UUWv.310935$Fo3.68916@fx09.iad> X-Newsreader: Forte Agent 6.00/32.1186 X-No-Archive: YES MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 108.79.217.224 X-Trace: sv3-bdsH4sHQ1hVFYfW5wxyFjxAAEdaaMjYp3eKqqLtfheEo2Q/9W8hqy6QbzmxDW1bs4FWupp8KoWbrbic!uCAsa2waUsPATaPrvPM4qeGtCt2ehpSsE29fKMqPBgRNIb08zO3tGsPEJpXtUNSvMpSpLgkI6ZBZ!rRNYavg923ZzlLr8DCZBkMBT9pA3 X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 4093 Xref: number.nntp.giganews.com comp.lang.ada:189294 Date: 2014-10-01T22:13:26-04:00 List-Id: On Wed, 01 Oct 2014 09:15:02 -0600, Brad Moore 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 >> 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/