[Cryptography] Swift and cryptography

Peter Trei petertrei at gmail.com
Thu Jun 12 13:37:38 EDT 2014


Arnold Reinhold <agr at me.com> wrote:

> I started this thread asking what other features Swift should have for
security. The
> two I came up with are a circular shift operator and class destructor
semantics that
> do not equate x=0 with a no-op.  People tell me that the latter is
platform dependent,
> though I am not clear why.

(It's been said that the fastest way to get an informed answer on the
Internet is to
post an uninformed opinion. So maybe someone who actually knows what the
problem
is will respond if I post this...)

I think the problem is that there are a lot of OS level operations that can
prevent proper
sanitization, and which are hard to fix at a language level. OSs have
historically been
designed to be time-efficient, in ways that conflict with security.

1. OSs supply memory management services. For efficiency, they generally
don't clear
memory when it's returned to the pool, or when reallocated.
2. OSs swap program space to disk and back. Same problem as above.
3. Machine level stack operations move the SP up and down, without clearing
memory
that's been popped off.

4. Optimizers will eliminate code which sets a value which is never read.

Generally, programs don't get the option to tell the OS to do otherwise.
This would
be a nice addition to an OS, but isn't part of the language. It is clearly
platform (OS & HW)
dependent.

1 & 2 could be fixed at the OS level, at some cost of memory (for
sensitivity flags) and
time (for clearing). 3. would need to be fixed at the microcode or HW
level, in instructions
that modify the stack. This would get tricky if you want to specify what's
sensitive,
and what's not. Tagged memory would make it a lot easier.

Further from the metal, things might be easier for dealing with (4) above.
I could
imagine a 'sensitive' key word on declarations and mallocs (or your
languages'
equivalent) which would tag that entity as one which which must be cleared
when it goes out of scope - I think this would be easier than having to
explicitly
clear it in a destructor.

A 'do not optimize' keyword would be difficult to implement, since code so
labeled
may call code which doesn't have the keyword, and which should be subject
to
optimization in most cases. When do you propagate the property down the call
tree, and when not?

Peter Trei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140612/06e86f41/attachment.html>


More information about the cryptography mailing list