[Cryptography] Swift and cryptography

[Jerry Leichter]

On Jun 12, 2014, at 1:37 PM, Peter Trei <petertrei at gmail.com> wrote:
Just to clear up a minor point before panicky rumors spread:
> 1. OSs supply memory management services. For efficiency, they generally don't clear memory when it's returned to the pool, or when reallocated.
No *OS* in many years (maybe since Windows 95 or so) has handed uninitialized memory to programs.  That's way too big a security hole.  What you get from an OS is zeroed pages.  As to *when* they are zeroed ... that depends.  Most OS's have a concept of a "demand 0 page", which is logically added to your process but marked inaccessible to you.  When you first access it, the hardware page faults.  The OS finds and zeroes a page of real memory, maps that real memory to your process, and lets you proceed.  Not super-high-security - sensitive data can sit in physical memory for long periods of time - but simple and efficient.  (It's surprisingly common for a process to want to re-acquire a page that got bounced from its working set.  If it hasn't been handed to anyone else, it can simply to returned to the original process.)

Some OS's have a background scrubber process to find pages of free memory and zero them, but in my experience this is unusual.

*Libraries* that allocate memory *within* a process, on the other hand, usually do *not* zero the memory, either on allocation or on deletion.  In C, you have a choice on the allocation side:  malloc() returns memory with whatever was there, calloc() zeroes the memory first.  Some libraries fill deleted memory with a distinctive pattern - e.g., 0xDEADBEEF - to help catch attempts to use freed memory.  (Often this is done only in debugging mode.)

> 2. OSs swap program space to disk and back. Same problem as above.
Security-aware systems use encrypted swap.  (Zeroing "disks" is expensive and increasingly ineffective:  The "disks" may be SSD's, where writing to a given block is redirected to some block you can't control.)

                                                        -- Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140612/fc554d4d/attachment.bin>