You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 2021-05-19 05:54:12
Deterministic ECC key generation
Hi,
I have been looking at tweaks that would be required to make SynECC support deterministic key generation and derivation based on a seed phrase.
That could be achieved by feeding getRandomNumber a CSPRNG based on the seed, however, getRandomNumber calls TAESPRNG.Fill, where the Main CSPRNG can be specified, but it can only be specified globally, and it is potentially called from all over the place. So not deterministic without involving global locks and/or singe threading.
Alternatively it would be possible by adapting ecc_make_key_pas, where that would be trivial, but from looking at the comments in the code, that brings two questions 
Is ecc_make_key_pas implementation safe in Delphi Win32 ? There is a comment about needing "proper UInt64 support at compiler level", not sure what it applies to exactly.
How safe / resilient to side channel or timing attacks is the Pascal implementation vs the C one ? is it more a stopgap solution for ARM, or are the issues just performance ones ?
Thanks!
Offline
#2 2021-05-19 09:15:23
Re: Deterministic ECC key generation
Only very old Delphi has trouble with UInt64 - before Delphi 2007 IIRC.
The pascal implementation is a rewrite of the C version in plain pascal, so both share the same behavior.
Deterministic key generation is something weird and unsafe by design.
Online
#3 2021-05-19 11:09:08
Re: Deterministic ECC key generation
Thanks, so safe. The context I am foreseeing would not be very sensitive as far as key generation goes (basically on user demand rather than automated)
I disagree on deterministic key generation, with a secure seed phrase, the security is comparable or higher than a classic password-protected storage (as demonstrated by HD wallets in the crypto world), and it makes backups and recovery more foolproof (both against data loss and attacks against backups). Vulnerability of the CSPRNG (not so rare in VMs) is eliminated.
Offline
#4 2021-05-19 12:54:16
Re: Deterministic ECC key generation
The mORMot CSPRNG is by default safe, even if the HW or OS PRNG is compromised.
I still don't see any use case for asymetric key generation from a password.
And some problems come to my mind:
1. If you change your password, you also change your key pair, which might have consequences in whatever system you are envisioning.
2. Good password hashing requires a salt, which is not a secret value, but should not be fixed either. You would need a storage space for that salt, somewhere.
3. The resulting public key would, by construction, be usable in an offline dictionary attack.
The first one is a big concern to me. Being able to change the password without changing the key itself is IMHO mandatory.
Online
#5 2021-05-19 15:04:34
Re: Deterministic ECC key generation
Usage purpose is for sharing of secure notes, but without a centralized server controlling access to the notes (and thus having access to everything), so something closer to a password vault or PGP.
> If you change your password, you also change your key pair
In the scheme, the password/seed phrase define everything: the "login" is public and untrustable (and amenable to DB admin abuse), tieing password changes to pubkeys is a feature.
If a password is suspected to be compromised, then the keys should be revoked ASAP, as they could be compromised and they are what matters.
Merely changing a weak password without revoking its keys would be pointless.
> Good password hashing requires a salt, which is not a secret value,
The "login" would be something universally unique and human-friendly, like an email, and the salt would be that unique login + random salt provided per user by the server.
The client app can also use a pepper, stored on the user hardware, and backed up by the user wherever he/she wants.
At setup (or reset) of an "account", you would register the pubkey(s) on the server, which other users could use as a "phonebook" in the first steps of sharing notes.
Any changes in pubkeys for a given login would be tracked / detectable, and serve as a first line of defense against impostors.
For an actual password change, the user would post a notification of the new pubkey(s) with the old key(s), then it's up to interlocutors to accept the change (or not, leaving the possibility to confirm through other channels).
If a basic user forgets a password completely, then recovery would be through the notes he shared, that other users could share back again.
In a corporate setting, automatic sharing to a recovery account could be used (with the recovery seed kept offline or on a secure element)
> The resulting public key would, by construction, be usable in an offline dictionary attack.
Yes, but unlike in a password-protected access, there is neither a clear-text database nor a server-side decryption key to be leaked (or attacked).
This is a tradeoff: the cost of an offline attack would have to be way higher than more classic attacks against the server, backups or plain old social engineering.
The cost comes from the dictionary attack needing to be against each user's keys, with an access to the per-user random salt 'and pepper), and attacking a user's data will not help attacking another user's data.
On the password hashing side, I'm currently looking at a Argon2id and BalloonHash for password hashing (memory hard all the way, logic gets ever faster and more parallel, but memory access keeps lagging).
Offline
#7 2021-05-21 19:34:28
Re: Deterministic ECC key generation
Well, deterministic approaches are quite common these days, and the literature leans heavily their way.
Traditional approaches of encrypting a growing database of private keys are getting abandoned in fields where security is paramount and data loss is not acceptable.
They have proved to be just as resilient to attacks (provided the seed is truly random), while being more resilient to data-loss and corruption.
For instance you can have a look at BIP 0032 for a now battle-tested use case of deterministic key generation, and there are schemes for post-quantum resilience as well, should that materialize (f.i. https://dl.acm.org/doi/10.1145/3372297.3423361)
Offline
Pages: 1