技术控

    今日:105| 主题:49390
收藏本版 (1)
最新软件应用技术尽在掌握

[其他] CECPQ1 results

[复制链接]
我在等我的永恒- 发表于 2016-11-29 10:26:16
64 4

立即注册CoLaBug.com会员,免费获得投稿人的专业资料,享用更多功能,玩转个人品牌!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
In July my colleague, Matt Braithwaite,    announcedthat Chrome and Google would be experimenting with a post-quantum key-agreement primitive in TLS. One should read the    original announcementfor details, but we had two goals for this experiment:  
  Firstly we wanted to direct cryptoanalytic attention at the family of Ring Learning-with-Errors (RLWE) problems. The algorithm that we used,    NewHope, is part of this family and appeared to be the most promising when we selected one at the end of 2015.  
  It's very difficult to know whether we had any impact here, but it's good to see the recent publication and withdrawal of    a paperdescribing a quantum attack on a fundamental lattice problem. Although the algorithm contained an error, it still shows that capable people are testing these new foundations.  
  Our second goal was to measure the feasibility of deploying post-quantum key-agreement in TLS by combining NewHope with an existing key-agreement (X25519). We called the combination CECPQ1.
  TLS key agreements have never been so large and we expected a latency impact from the extra network traffic. Also, any incompatibilities with middleboxes can take years to sort out, so it's best to discover them as early as possible.
  Here the results are more concrete: we did not find any unexpected impediment to deploying something like NewHope. There were no reported problems caused by enabling it.
  Although the median connection latency only increased by a millisecond, the latency for the slowest 5% increased by 20ms and, for the slowest 1%, by 150ms. Since NewHope is computationally inexpensive, we're assuming that this is caused entirely by the increased message sizes. Since connection latencies compound on the web (because subresource discovery is delayed), the data requirement of NewHope is moderately expensive for people on slower connections.
  None the less, if the need arose, it would be practical to quickly deploy NewHope in TLS 1.2. (TLS 1.3 makes things a little more complex and we did not test with CECPQ1 with it.)
  At this point the experiment is concluded. We do not want to promote CECPQ1 as a de-facto standard and so a future Chrome update will disable CECPQ1 support. It's likely that TLS will want a post-quantum key-agreement in the future but a more multilateral approach is preferable for something intended to be more than an experiment.
友荐云推荐




上一篇:Beating the Compiler
下一篇:Redis单机主从高可用性优化
酷辣虫提示酷辣虫禁止发表任何与中华人民共和国法律有抵触的内容!所有内容由用户发布,并不代表酷辣虫的观点,酷辣虫无法对用户发布内容真实性提供任何的保证,请自行验证并承担风险与后果。如您有版权、违规等问题,请通过"联系我们"或"违规举报"告知我们处理。

明丞明k 发表于 2016-11-29 11:22:22
very good!
回复 支持 反对

使用道具 举报

king2014 发表于 2016-11-29 11:56:44
兄弟我先抛块砖,有玉的尽管砸过来。
回复 支持 反对

使用道具 举报

送到看的 发表于 2016-11-29 12:46:50
报,报,报,报,报告楼主,我来了!
回复 支持 反对

使用道具 举报

369854 发表于 昨天 23:46
楼上的别说的那么悲观好吧!
回复 支持 反对

使用道具 举报

*滑动验证:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

我要投稿

推荐阅读

扫码访问 @iTTTTT瑞翔 的微博
回页顶回复上一篇下一篇回列表手机版
手机版/CoLaBug.com ( 粤ICP备05003221号 | 文网文[2010]257号 )|网站地图 酷辣虫

© 2001-2016 Comsenz Inc. Design: Dean. DiscuzFans.

返回顶部 返回列表