EL PASSO is an efficient and lightweight privacy-preserving single sign-on system. It uses non-interactive zero-knowledge proofs and Pointcheval-Sanders signatures to allow a user to anonymously prove credentials and selectively disclose attributes to different services without revealing their long-term secret or allowing the services to link their activities. The system employs threshold encryption to allow misbehaving users to be reported while preserving their anonymity from the identity provider.

1. EL PASSO
Efficient and Lightweight Privacy-preserving Single Sign On
@fdenis - OCTO

2. Shifumi@edge
https://shifumi.edgecompute.app

3. can be e
ffi
ciently computed
Without , doesn’t reveal any information about .
Given ,
fi
nding another pair so that is
hard.
Even if is known.
Even if
h ← Hk(m)
h
k h m
h (k′

, m′

) Hk′

(m′

) = h
k
k = k′

Commitments - MACs

4. Generate a random key
Choose a move in {✊,✋,✌}
Compute and send : commitment
Then reveal : proof, that anybody can
verify with public parameters
k
m
Hk(m)
(k, m)
Commitments - Shifumi game

5. Great, but we had to reveal everything.
Including the secret
Fine here, because we use these only once.
But would there be a way to prove that we
know a secret without disclosing it?
k
Commitments - Shifumi game

6. We are going to choose a setup where:
can be e
ffi
ciently computed
But given and , recovering is assumed to be hard.
Even if is secret, it is safe to make public
(until large quantum computers become real)
A ← Ga
Ga
G A a
a Ga
Schnorr proofs - Discrete log problem

7. Pick a secret
Make public
Goal: prove that we know without
disclosing it.
is already known by the veri
fi
er.
a
A ← Ga
A
a
G
Schnorr proofs

8. Pick a secret
(public)
Pick a random group element
(public) commitment
: challenge sent by the veri
fi
er
(public) proof
a
A ← Ga
v
V ← Gv
c
r ← v − ac
Schnorr proofs

9. Secret
(public)
Random group element
(public) commitment
: challenge sent by the veri
fi
er
(public) proof — requires knowledge of
Veri
fi
cation: check that — public parameters
a
A ← Ga
v
V ← Gv
c
r ← v − ac a
Gr
⋅ Ac
= V
Gr
⋅ Ac
= Gv−ac
⋅ Gac
= Gv
= V
Schnorr proofs

10. : challenge sent by the veri
fi
er
Requires a round-trip.
Doesn’t work asynchronously.
Let’s
fi
x this with the Fiat-Shamir heuristic.
c
Schnorr proofs

11. Produces a challenge that the prover doesn’t
have much control over
Not random, but good enough in practice.
The prover is “challenging itself”
The protocol becomes non-interactive!
c ← H(A, V, fastly, …)
Non-interactive Schnorr proofs

12. NIZKP - Non-Interactive Zero Knowledge
Proof.
Can be used to prove knowledge of a secret
without revealing it. Multiple proofs can be sent
to a veri
fi
er anytime, without any round trips.
What if we include a message in the
computation? We get a signature system.
Here, the Schnorr signature system.
Non-interactive Schnorr proofs

13. : generate a secret and a
public counterpart
signature (commitment+proof)
A valid signature that the signer knew about
and the secret without revealing the secret.
generate() a
A
sign(a, m) →
verify(A, m, sig) → {valid, invalid}
m
Schnorr signatures

14. RSA signatures: md
(mod n)
RSA

15. RSA signatures:
If is a valid pair for a given public key,
is also a valid pair.
It can be veri
fi
ed with the same public key.
They look very di
ff
erent. Even the signer cannot tell that
But any valid pair means that, at some point, the signer
signed something.
md
(mod n)
(m, sig) (mr
, sigr
)
(mr
, sigr
) ≡ (m, sig)
RSA

16. Maybe the signature was issued because we
bought something.
Or were granted access to something - we
got a “virtual ticket” or a “virtual pass”
The message itself may not even matter.
Owning a valid signature does. Even if it’s not
the original one.
On the signature itself

17. If we get a signature and present a variant of
it a veri
fi
er, both events cannot be linked.
Untraceable payments.
Anonymous tokens, where signatures issued
by an identity provider are not the same as
the ones presented to services.
Blind / randomized signatures

18. The previous example was textbook RSA.
Real RSA doesn’t sign a message, but a hash of it.
Still possible to get a (message, signature) pair
signed, and compute a di
ff
erent pair that veri
fi
es.
But only one.
For a “single-use ticket” this is
fi
ne. Not for a
“pass”.
Real RSA

19. (“Location: New York”, signature)
We get this from an identity provider.
What if we use the same signature for that
attribute on di
ff
erent services?
The signature becomes a global cookie!
Randomized signatures

20. Can we randomize signatures?
Without interacting with the signer?
(“Location: New York”, signature1)
(“Location: New York”, signature2)
…
(“Location: New York”, signatureN)
Randomized signatures

21. PS signatures are randomizable. As many
times as we want.
Multiple messages can be signed at the same
time (and the signature has a constant size)
A signature can be computed for a subset of
the messages, without interacting with the
signer
-> Selective disclosure.
Pointcheval-Sanders signatures

22. These are the main
building blocks of
EL PASSO!
EL PASSO

23. User generates a long-term secret
Will be used to generate a unique user id for
every service to log on
Service speci
fi
c user id:
Remember Schnorr proofs?
s
sid = H(domain)s
EL PASSO

24. Credentials issuance:
The identity provider computes a unique
(multi-messages) PS signature for user
attributes (name, location, email, …), hidden
attributes (“public” counterpart of ), as well
as a timestamp.
s
EL PASSO

25. Credentials usage:
The signature is randomized, then the credentials
or a subset are presented.
Service speci
fi
c user id:
The client also presents a proof of knowledge for
Prevents sybil attacks.
sid = H(domain)s
s
EL PASSO

26. How to register a new device
What to do if a device is stolen/compromised
How to handle 2FA
…
How to mitigate abuse?
EL PASSO

27. How to mitigate abuse?
Threshold encryption
The user id, as stored by the Identity Provider,
is encrypted in a way that multiple secret
keys are required in order to decrypt it.
This encrypted (randomized) ID may be
required by a service.
EL PASSO

28. If a user misbehaves, a service can report the
encrypted ID to a “decryption authority”
Multiple authorities must collaborate in order
to reveal the actual ID and report it to the
Identity Provider, so that an action can be
taken.
EL PASSO

29. WebAssembly on the client.
Credentials and secrets stored in the
browsers’ password manager.
Implementation

30. How do we trust the WebAssembly code we
got?
How can it access shared secrets, from any
origin?
If it’s even possible, is that a good idea?
Missing a lot of details — this is not a
speci
fi
cation.
Implementation

31. Thanks!