Closed rrottmann closed 8 months ago
Hi, thanks for the report.
There is actually no need to have access to special hardware as this can be reproduced with the virtualsmartcard example. It looks indeed like Opcard rejects non-canonical public keys for X25519 key agreements, which does not appear to be the case of other X25519 implementations. I will look into it.
Hi, thanks for the report.
There is actually no need to have access to special hardware as this can be reproduced with the virtualsmartcard example. It looks indeed like Opcard rejects non-canonical public keys for X25519 key agreements, which does not appear to be the case of other X25519 implementations. I created an issue with our X25519 implementation: https://github.com/ycrypto/salty/issues/31
Closing as this issue has been fixed upstream.
Summary
Investigation is needed (possibly with a Nitrokey 3 and a debugging probe), why deriving a shared secret using
calculate_shared_secret(card, bytearray(b"\xff" * 32), pin)
does not work while random public keys do work.Further Information
Thread at Nitrokey Support forum.
Relevant info provided by the developer of ~arx10/openpgpcard-wireguard-go: