You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the exposed API, a Python program (and, without some deeper knowledge, even a Rust program) that loads a private key and a credential has no way of finding out that the configured credential does not match the provided private key.
Steps I suggest for enhancing the API, at least from a Python PoV:
Take the private key as a private key object, alternatively (similar to how we take an AutoCredential)
Give the private key object a method to verify that any given credential matches it. (I'm not sure our crypto API has the tools to do that; worst case, it can be done by generating a key pair and verifying that GXY = GYX).
By-catch (and that'll be good for algorithm agility anyhow): Add a constructor for the private key object that parses a COSE key, and a serializer. (Nice extra property: once a key is loaded, the Python program can't access it any more outside EDHOC).
By-catch: Have key pair generation produce a key object.
@geonnave, is there a plan for #277 yet? (That'd influence how the private key object is best done)
With the exposed API, a Python program (and, without some deeper knowledge, even a Rust program) that loads a private key and a credential has no way of finding out that the configured credential does not match the provided private key.
Steps I suggest for enhancing the API, at least from a Python PoV:
@geonnave, is there a plan for #277 yet? (That'd influence how the private key object is best done)
Blocks: chrysn/aiocoap#377
The text was updated successfully, but these errors were encountered: