2

RFC 4880是描述 OpenPGP 加密标准的文档，其根源在于1998年发布的RFC 2440（那是16 年前，据说在 64 位系统出现之前）。两种规范都说明了如何处理时间戳：

3.5 . 时间字段

时间字段是一个无符号的四字节数字，包含自 UTC 1970 年 1 月 1 日午夜以来经过的秒数。

是否应该尝试尽可能地遵循 RFC （并且，在这里，有一天会面临一个甜蜜的2038 年错误）？开发人员不遵循部分标准/规范/RFC（尤其是在密码学方面）是否“有风险”，因为它们已经被视为可能已经过时了？

我有点害怕问，因为这个问题听起来很傻，但是如果我以我自己的方式“实现 RFC 4880”，那它就不再是官方的事情了。那么，针对她认为“过时”的规范部分，开发人员应该做的最好的事情是什么？没有什么？

4

1 回答 1

2

首先：我认为您问题中的示例是错误的。RFC4880使用无符号32 位整数。y2k38 问题是有符号32 位整数的问题。根据 Wikipedia，无符号 32 位整数可以工作到 2106 年。还有一点时间。

回答您的问题：我认为最好的方法是与 RFC 工作组/RFC 的作者联系，并告诉他们过时的情况。也许，后续 RFC 将解决该问题。

对于您的示例，我认为您可以避免联系 OpenPGP WG。我认为，在 2106 年之前会有很多更新，我怀疑 V5 密钥具有 8 个八位字节的时间字段。

于 2014-12-30T03:14:04.450 回答