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

input key size dependant AES key -hashes and -sizes #118

Closed
wants to merge 4 commits into from
Closed

input key size dependant AES key -hashes and -sizes #118

wants to merge 4 commits into from

Conversation

Logan007
Copy link
Collaborator

@Logan007 Logan007 commented May 31, 2019

This pull request applies the scheme of #101 to generate internal key material and key sizes from the input key.

As a by-product, TRANSOP_AES_IV_SEED_SIZE now can range between 0 and 16 allowing the compiler savvy user to determine the trade-off between highest security (=16 byte random IV seed, longer packet) and (=0 byte random IV seed to be transmitted, shorter packet). Default is the well discussed and balanced value of 8.

These changes break compatibility to current dev version as key material now is generated in a different way than before, all edges would need to be updated.

This was referenced May 31, 2019
transform_aes.c Outdated Show resolved Hide resolved
transform_aes.c Outdated Show resolved Hide resolved
transform_aes.c Outdated Show resolved Hide resolved
transform_aes.c Outdated Show resolved Hide resolved
@Logan007
Copy link
Collaborator Author

Logan007 commented Jun 5, 2019

Thank you for your feedback. Will go through it, maybe somewhen during the weekend and "update" the pull request.

@Logan007
Copy link
Collaborator Author

Logan007 commented Jun 9, 2019

I have restored iv_seed back to uint64_t to get back to the former invocation of rand(). Thus, TRANSOP_AES_IV_SEED_SIZE can not be handled in a flexible way, it has to stick to 8.

Maybe that would be worth a new issue discussion...

@Logan007
Copy link
Collaborator Author

Logan007 commented Jun 9, 2019

The "Resolve Conflicts" button just produces a never-ending-wheeling copy cat... any hint on how to resolve the indicated conflict (which should already be resolved in code)?

@Logan007
Copy link
Collaborator Author

Logan007 commented Jun 10, 2019

Mmmmh , still conflicting... "Resolve Conflicts" not working... I am lost.

Will try to make a new pull request.

@Logan007 Logan007 closed this Jun 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants