【问题标题】:Standard, non-SSL, HTTP encryption标准、非 SSL、HTTP 加密
【发布时间】:2011-09-16 21:54:41
【问题描述】:

我们正在将一个 HTTP RESTful 接口放入我们的嵌入式平台。硬件太有限,无法支持 SSL,但我们确实在其他方面使用 AES 加密。

我正在考虑使用带有共享密钥的 AES 来加密数据。还有什么其他方法至少是一种通过 HTTP 进行加密的标准方式吗?

【问题讨论】:

标签: http encryption ssl embedded aes


【解决方案1】:

加密 HTTP 的标准方式 SSL(或其后继 TLS,如今)(当时称为 HTTPS)。

正如 GregS 在评论中所问的那样,您的平台以何种方式对 SSL 过于有限,但仍允许 AES?它是否没有足够的计算能力/内存来进行模幂运算(在 RSA、DSA、Diffie-Hellman 中使用)?

那么您也许可以使用 TLS 的预共享密钥版本。 RFC 4279 定义了具有预共享密钥身份验证的密码套件,其中 TLS_PSK_WITH_AES_128_CBC_SHA 看起来像只需要 AES 和 SHA-1,不需要模幂运算。

当然,如果存在攻击者可以获取机密的危险(例如通过破解您的设备),您不应该使用它,因为它还允许读取所有先前注册的连接(与 Diffie-Hellman 相比,为每个会话提供一个新的会话密钥)。

【讨论】:

  • @Craig:感谢您的编辑……看来我累了就不应该回答了。
  • 您的假设是正确的,模幂运算和随机数生成是问题所在。您指向的 RFC 正是我所需要的,或者至少它让我指向了正确的方向。
  • 我想你仍然需要随机数来初始化向量。不过,可以从像 AES 这样的分组密码构建 PRNG。 (例如,请参阅ANSI X9.31。)
【解决方案2】:

发现这个宝石:10 行 C 语言中的 Diffie-Hellman 密钥交换 http://www.cypherspace.org/rsa/dh-in-C.html

【讨论】:

  • 不过,我不会真正将这种混淆代码称为 gem
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2013-12-25
  • 2010-10-30
  • 1970-01-01
  • 2019-01-02
  • 2016-08-05
  • 2016-06-03
  • 2011-03-28
相关资源
最近更新 更多