Home/ Questions/Q 978669
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T04:05:35+00:00

I’m working on a one-time password application, using the hotp algorithm (RFC 4226). I’ve

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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

    • 0