Android 和服务器之间的密钥不同
我正在开发一个一次性密码应用程序，使用 hotp 算法（RFC 4226）。我有一个用于生成 otp 的 Android 应用程序（通过模拟器），以及一个用于验证的服务器端应用程序。就其本身而言，两者都工作良好并通过了测试。
但是，我在设备上生成的密钥与我在服务器上生成的密钥不同，即使输入是硬编码的并且它们之间相同。这导致设备和服务器上生成不同的一次性密码，从而破坏了我生成有效一次性密码的能力。我试图找出为什么会发生这种情况，以及我是否可以做些什么。
服务器和设备模拟器之间用于构造 SecretKey 并从密钥生成一次性密码的代码是相同的。我检查了设备和服务器上关键规范中的字节，它们是相同的。然而，当我查看来自 SecretKey.getEncoded() 的字节时，SecretKeyFactories（均来自 DESedeKeySpecs）生成的密钥存在细微的相差一的差异。如果我使用 DES 而不是三重 DES，我会看到类似的差异。
有趣的是，在我的 Android 项目中，KeySpec 和生成的 SecretKey 中的字节是一致的（虽然被截断），但在服务器上，KeySpec 和生成的 SecretKey 之间的字节偶尔会存在相差一的差异。这是正常的吗？我读过一些有关使用 DES 和三重 DES 时奇偶校验位更改的内容，所以我不确定这是否是一个问题。
我也知道 Android 使用 Bouncy Castle，但我的服务器使用 SunJCE。我的理解是，这不应该出现问题，我想知道在使用两个不同的提供程序时这是否是已知的情况。我获得 Bouncy Castle 服务器端的能力非常有限。
请给点建议和启发？
I'm working on a one-time password application, using the hotp algorithm (RFC 4226). I've got an Android app (via simulator) for otp generation, and a server-side app for validation. On their own, both are working fine and passing tests.
However, the secret key I'm generating on my device is not the same as the secret key I'm generating on the server, even when the inputs are hardcoded and the same between them. This leads to different one-time passwords being generated on the device and the server, which ruins my ability to generate valid one-time passwords. I'm trying to figure out why this is happening, and if there's anything I can do about it.
The code is identical between the server and the device simulator for constructing SecretKeys and generating one-time passwords from the keys. I've checked the bytes in the keyspecs on the device and the server, and they're identical. However, the keys generated by the SecretKeyFactories (both from DESedeKeySpecs) have subtle off-by-one differences when I view the bytes from secretKey.getEncoded(). I see similar differences if I use DES instead of triple DES.
What's interesting is that in my Android project, the bytes in the KeySpec and the generated SecretKey are consistent (though truncated), but on the server, there are occasional off-by-one differences in the bytes between the KeySpec and generated SecretKey. Is this normal? I read something about parity bit alterations when using DES and triple DES, so I'm not sure if this is a problem.
I also know that Android is using Bouncy Castle, but my server is using SunJCE. My understanding was that this shouldn't present a problem, and I'd like to know if this is a known occurence when using two different providers. I have very limited ability to get Bouncy Castle server-side.
Advice and enlightenment, please?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
看起来其他人已经发现了这个问题并找到了临时解决方案。电话上的 BC 实现与 SunJCE 在生成密钥时处理奇偶校验位的方式有所不同。看起来 Bouncy Castle 可能会发布更新来解决此问题：
http:// /code.google.com/p/android/issues/detail?id=3143
Looks like someone else already detected the problem and an interim solution. It's a difference between how the BC implementation on the phone and SunJCE handle parity bits when generating secret keys. Looks like Bouncy Castle might be releasing an update to address this:
http://code.google.com/p/android/issues/detail?id=3143