[e-lang] Introducing Emily, a High Performance Language For Secure
cap at isg.axmor.com
Thu Feb 23 15:44:30 EST 2006
David Wagner wrote:
> Constantine writes:
>> 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?
This is a good analogy. If you close one door, you have one less door to
watch out during program design. Try playing Quake or Counter Strike to
understand a security difference ;].
> 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.
Yes. But you have to cosider other factors like communication time and
amount of possible communication attempts.
> 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.
It is possible to design program that is more resistant to such attack.
For example careful usage of the Factory pattern can limit an attacker
to leaking exactly one bit with exception in case of some algorighms. So
calling 2048 times, you will get the same bit 2048 times. But we are
talking about an example that lacks the any details and it cannot be
argued with because of that.
> 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
> programming language.
How much information can be leaked though a single unexpected exception
is a datum that can be used in reasoning. Whether it is useful for
reasoning in some particular situation is a complently separate issue.
Also reasoning about code during design or maintenance is a two-way
process. The code is often updated to make reasoning easier.
If it comes to guarntees, there is no meaningful guarantee that NP != P.
However we are not throwing out our crypto away. Even more, crypto is
used just to slow down an attacker even if we assume NP != P.
More information about the e-lang