[Cryptech Tech] Roadmap & remarks about the opportunity of developing a secure TOR router on the Novena platform.

[Bernd Paysan]

Am Sonntag, 3. August 2014, 09:42:12 schrieb Benedikt Stockebrand:
> I've taken a look at D some time ago, but it got rather quiet about it.
> Maybe some time I'll find the time to give Go a chance, but I'm not sure
> when, and if at all.

It fixes at least the worst offenders in C.  I'd say, if you are looking for a 
traditionally compiled language without much extensibility (i.e. no DSLs), and 
without an interactive shell to try things out, Go is a pretty reasonable 
language with a C-like syntax.  For me, no interactivity, and no big 
extensibility is a show-stopper.

As the biggest problem with security is feature bloat, it certainly isn't slim 
enough, though.

> The weaknesses with TCP/IP and especially SSL aren't all implementation
> related anyway, but design problems.  They all suffer from significant
> feature bloat, APIs that are a pain in the backside to use as is, and
> implementations that weren't necessarily built with the level of
> security awareness they would have deserved by our today's standards.
> 
> Or put more bluntly: You may be trying to fix a minor hole with lots of
> enthusiasm but completely ignore the much larger holes elsewhere.  This
> is good to get started, but it won't win you any much until you
> eventually address all the issues involved.

I've some other issues with pushing down security relevant issues to hardware 
description languages (Verilog or VHDL): There is the law of constant 
complexity: If you have such an issue, the complexity is not changing, when 
you move it through the layers of your stack.  However, the actual effort is 
changing, it is considerably higher the lower you get (the effort to manage 
the same amount of complexity).  If I have a compiler that needs to check 
boundaries of array accesses, I have to insert some comparisons - that's all.  
If I do that on a lower level, I have to think about segment descriptors, and 
compare accesses through these segments with their limits; find a way to keep 
the segment descriptors and limits inside some registers, and so on.

Intel solved that with a pretty complex microcode which they apparently don't 
dare to change since the 286/386 days.  Solving that in a HDL is even more 
complex.  I won't say it's not doable, and if you do that right, it may not be 
very complicated.  But the idea that moving things down the abstraction layer 
makes them easier to write correct is IMHO foolish.

If you design for doable-in-hardware, you have to take ten times the effort in 
making it simpler.  Then it's trivial to get it right in software, and doable 
in hardware.  The security gain from hardware are then

* speed (you can use all the parallelism there is)
* more difficult to modify (an attacker can't just load software to change 
your network stack, he has to replace your hardware)

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cryptech.is/archives/tech/attachments/20140804/74e95992/attachment.sig>