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

Elligator inverse map #924

Closed
nitrieu opened this issue Feb 1, 2020 · 4 comments
Closed

Elligator inverse map #924

nitrieu opened this issue Feb 1, 2020 · 4 comments

Comments

@nitrieu
Copy link

nitrieu commented Feb 1, 2020

Hi there,

From what I understand, your code supports the map in the forward direction (e.g. takes a random field element and produces a group element). Do you have a code for backward direction, which represents the group element as a field element like this?

Thanks.

@jedisct1
Copy link
Owner

jedisct1 commented Feb 1, 2020

Hi!

While Elligator is useful for the hash-to-group-element operation, I've never found any practical use case for the inverse map. DPI circumvention isn't a very compelling argument, as encrypted channels are simply detected using entropy evaluation instead of trying to spot public keys. If necessary, public keys can be encrypted to hide the sender in addition to providing indistinguishability from randomness.

So, it is not implemented in libsodium or wasm-crypto.

It should be pretty straightforward to implement, but I don't have any code for this at the moment.

@jedisct1 jedisct1 closed this as completed Feb 1, 2020
@LoupVaillant
Copy link
Contributor

If necessary, public keys can be encrypted to hide the sender in addition to providing indistinguishability from randomness.

(Emphasis mine)

Sorry to bother you on a closed issue, but you may have written that part a bit quickly: initiating a first connection requires an unencrypted ephemeral key to bootstrap the process, and those are not indistinguishable from random. Curve25519 points are encoded in 255 bits, and they satisfy a condition that only half random numbers fulfil. That's 2 bits of bias, and easily distinguished from random. (Of course one of those bits is easily masked. The other requires Elligator or equivalent.)

Whether we need indistinguishability from random is another question, which I am not qualified to answer.

@jedisct1
Copy link
Owner

To encrypt the public key in the initial handshake, you need a PSK or a previous session key (as in 0 RTT schemes).

I've still never seen any compelling use case for the foward map.

@LoupVaillant
Copy link
Contributor

Yep. I was just insisting that when cold contacting someone, you don't have a PSK yet, and therefore can't encrypt your ephemeral key. What you wrote was accurate, but I was afraid people might get the wrong idea, and think the ephemeral key is as good as random.

I was probably overreacting.

Repository owner locked and limited conversation to collaborators May 1, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants