Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

InputKeyingMaterial should be provided as SecretKey, not (only) as byte array #4

Closed
tititin42 opened this issue Jun 5, 2019 · 2 comments
Assignees
Milestone

Comments

@tititin42
Copy link

In order to provide compatibility with HSM, the input keying material should be directly provided as SecretKey.

At the moment, you recreate a SecretKey from a byte array, and provide it to the mac instance.

Whereas you should also provide a signature where we can provide a SecretKey which already contain the keying material.

This is preferred to keep compatibility with HSM, the input keying material is not always "readable" depending of the source of the keying material.

This also mean that the keying material should comes from the same source as the mac instance you are generating, but this is already covered by the fact you allow to provide the mac provider.

@tititin42 tititin42 changed the title InputKeyingMaterial should be provided as SecretKey, not byte array InputKeyingMaterial should be provided as SecretKey, not (only) as byte array Jun 5, 2019
@patrickfav
Copy link
Owner

Never thought about this, but the refactor should be easy enough. I will look into this.

@patrickfav patrickfav added this to the v1.1.0 milestone Jun 11, 2019
@patrickfav patrickfav self-assigned this Jun 11, 2019
patrickfav added a commit that referenced this issue Jun 13, 2019
This is to make the lib compatible to security framework that require
the use of the JCE to work properly (e.g. HSM front ends).

Breaks the hkdfMacFactory interface.

refs #4
@patrickfav
Copy link
Owner

Released in v1.1.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants