[e-lang] Introducing Emily, a High Performance Language For Secure
daw at cs.berkeley.edu
Thu Feb 23 12:40:20 EST 2006
>Restricting leakage over overt channels rasises economical cost of
>leaking data: leaking over covert channel requires more skill, usually
>has less bandwidth, and it is less relyable. So having it is better than
>not having it even if covert channels cannot be prevented.
Maybe this is just a difference in taste, but why bother closing one
door if you're going to leave another open?
I don't know why you think that exploiting covert channels requires a
lot of skill. Anyway, if you think attackers have little skill, take a
look at the incredible methods that are used to exploit buffer overruns.
Low bandwidth channels can still be devastating; it only takes 2048 bits
to leak my SSH private key, and then I'm toast. Reliability is a red
herring; Shannon taught us that you can trade reliability for bandwidth.
Sounds like you're proposing something that will at best be a roadbump,
and at worst tissue paper.
And having even one opaque UnhandledException is enough to communicate
data via exceptions. The callee can signal one bit by deciding whether
to throw an exception: normal termination means 0, an exception means 1.
Repeating 2048 times lets you leak a RSA key. The cost of this kind of
attack is so close to zero it can essentially be ignored.
I'd prefer a system where programmers can reason about their code and we
can make some meaningful guarantees. If we can't make any guarantees,
or if we're just going to kludge up something that will only slow an
attacker down for a few minutes, we can do that without inventing a new
More information about the e-lang