[Cryptography] It's all K&R's fault

[Watson Ladd]

On Sun, Apr 20, 2014 at 4:24 PM, Benjamin Kreuter <brk7bx at virginia.edu> wrote:
> On Sat, 2014-04-19 at 16:59 -0700, Bear wrote:
>> On Sat, 2014-04-19 at 18:10 -0400, Benjamin Kreuter wrote:
>>
>> There are different aspects of security that are important here.
>>
>> I am more confident that someone will not be able to get an application
>> written in Haskell or ML to do other than behave as its writer intended.
>> That is important in terms of security.
>>
>> I am more confident that someone writing in C will be able to create an
>> application that doesn't leave copies of information you want private
>> sitting around the system in public places.  That is also important in
>> terms of security.
>>
>> Now, if only I could be confident that the person writing in C had
>> *BOTHERED* to write an application that doesn't leave copies of
>> confidential information lying around, I'd feel better. But the person
>> writing in Haskell or ML, literally CANNOT avoid leaving copies of
>> data values lying around in memory.
>
> I do not think these issues are as orthogonal as you make it seem.  You
> cannot really say that an application does not leave copies of
> confidential data lying around without being confident that the
> application behaves as intended.  This is painfully apparent with
> heartbleed:  data is unintentionally copied because array boundaries are
> not enforced.

Why does it matter if we make copies in memory if they do not go to
unencrypted disk or can be seen by any other application, or leaked by
our application? Wiping memory and pinning to avoid swap assume that
1) the OS won't wipe memory between processes and 2) swap is
unencrypted.

In particular, even if I don't save keys to disk because I've pinned
them, I save confidential documents to swap because my editor doesn't
know how to deal with them. And if I encrypt swap, there isn't any
reason that keys landing there is a bad thing.

Sincerely,
Watson Ladd

>
> On the other hand, if we had the motivation, we could certainly create
> an ML that presents a "secure buffer" data type that cannot be copied
> and that will be cleared when it is no longer in use.  Then we would
> have a much stronger guarantee about "not-to-be-copied" data actually
> not being copied.
>
> -- Ben
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin