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

Make signatures non-deterministic #1353

Merged

Conversation

Projects
None yet
5 participants
@PlasmaPower
Copy link
Contributor

commented Nov 2, 2018

Advantage: resistance to side channel attacks
Disadvantage: signatures will be non-deterministic

@PlasmaPower PlasmaPower force-pushed the PlasmaPower:non-deterministic-signatures branch from d914884 to 41735f1 Nov 2, 2018

@PlasmaPower PlasmaPower added this to the V17.0 milestone Nov 2, 2018

@PlasmaPower PlasmaPower force-pushed the PlasmaPower:non-deterministic-signatures branch from 41735f1 to 2046b33 Nov 2, 2018

@renesq

This comment has been minimized.

Copy link

commented Nov 3, 2018

Are existing signature verification libraries compatible with this?
Are existing signature creation procedures still valid for a long time to come?

@PlasmaPower

This comment has been minimized.

Copy link
Contributor Author

commented Nov 3, 2018

Yes and yes

@PlasmaPower

This comment has been minimized.

Copy link
Contributor Author

commented Nov 6, 2018

I should probably add that there's no way to tell if a signature was generated with this method, unless you either have the private key, or you see two different signatures (which means at least one was clearly generated non-deterministically).

@rkeene rkeene merged commit f15b16e into nanocurrency:master Nov 8, 2018

1 of 2 checks passed

continuous-integration/appveyor/pr AppVeyor build failed
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@SergiySW

This comment has been minimized.

Copy link
Collaborator

commented Nov 9, 2018

Deterministic signtures was one of the main features of Ed25119
http://blog.cr.yp.to/20140205-entropy.html
https://tools.ietf.org/html/rfc8032#section-8.2

Of course there are different opinions
https://cybermashup.files.wordpress.com/2017/10/practical-fault-attack-against-eddsa_fdtc-2017.pdf
https://eprint.iacr.org/2017/985.pdf

Could we make proper cryptography audit of this change?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.