Erwin Hoffmann
2011-02-12 18:07:09 UTC
Hi together,
for those, who are interested:
DJB gave a talk on 27c3 'Hacker congress' (at December 28th, 2010) in Berlin:
"High-speed high-security cryptography encrypting and authenticating the whole internet"
In essence, Dan
- critices DNSSec from first principles ('CIA') and explaining possible amplification attacks, and addressing the problem of static signing keys,
- introduces briefly DNSSec with ECC and NYM deployed Public Keys,
- outlines CurveCP, a new protocol, using UDP services while encrypting the payload (asymmetrically) by means of ECC. This could be used for general HTTP traffic (instead using standard TCP).
--
What is interesting, challenging, and extraordinary is the approach - unlike TLS - to directly encrypt data with ECC and not to first negotiate a shared secret for (later) symmetrical en/de-cryption. Dan tries to convince the public that asymmetric cryptography by ECC is not heavy burdon on today's CPUs.
Sources:
His talk: http://cr.yp.to/talks/2010.12.28/slides.pdf
His life presentation: http://vimeo.com/18279777
--
Interesting enough, apart from Dan's approach, Google also tries to tie down the latency introduced by TLS (for instant HTTP traffic):
http://tools.ietf.org/html/draft-agl-tls-snapstart-00
--
Thus, given the current hardware capabilities, not the CPU load is problematic for encryption, but rather the (slow) current approach, to at first set up a security context/session and negotiate on a cipher.
Enjoy!
regards.
--eh.
PS: Sorry for potentially receive this mail twice. It is worth it!
for those, who are interested:
DJB gave a talk on 27c3 'Hacker congress' (at December 28th, 2010) in Berlin:
"High-speed high-security cryptography encrypting and authenticating the whole internet"
In essence, Dan
- critices DNSSec from first principles ('CIA') and explaining possible amplification attacks, and addressing the problem of static signing keys,
- introduces briefly DNSSec with ECC and NYM deployed Public Keys,
- outlines CurveCP, a new protocol, using UDP services while encrypting the payload (asymmetrically) by means of ECC. This could be used for general HTTP traffic (instead using standard TCP).
--
What is interesting, challenging, and extraordinary is the approach - unlike TLS - to directly encrypt data with ECC and not to first negotiate a shared secret for (later) symmetrical en/de-cryption. Dan tries to convince the public that asymmetric cryptography by ECC is not heavy burdon on today's CPUs.
Sources:
His talk: http://cr.yp.to/talks/2010.12.28/slides.pdf
His life presentation: http://vimeo.com/18279777
--
Interesting enough, apart from Dan's approach, Google also tries to tie down the latency introduced by TLS (for instant HTTP traffic):
http://tools.ietf.org/html/draft-agl-tls-snapstart-00
--
Thus, given the current hardware capabilities, not the CPU load is problematic for encryption, but rather the (slow) current approach, to at first set up a security context/session and negotiate on a cipher.
Enjoy!
regards.
--eh.
PS: Sorry for potentially receive this mail twice. It is worth it!
--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de