pake-kem
| Crates.io | pake-kem |
| lib.rs | pake-kem |
| version | 0.1.0-pre.5 |
| created_at | 2024-10-10 23:48:55.593706+00 |
| updated_at | 2025-10-22 21:47:11.998314+00 |
| description | An implementation of a password-authenticated key exchange (PAKE) based from a key encapsulation mechanism (KEM). |
| homepage | |
| repository | https://github.com/facebook/pake-kem |
| max_upload_size | |
| id | 1404712 |
| size | 98,022 |
Kevin Lewi (kevinlewi)
documentation
README
pake-kem 
An implementation of a password-authenticated key exchange (PAKE) based from a key encapsulation mechanism (KEM).
⚠️ Warning: This implementation has not been audited. Use at your own risk!
Documentation
The API can be found here along with an example for usage.
Installation
Add the following line to the dependencies of your Cargo.toml:
pake-kem = "0.1.0-pre.5"
Threat model
This is NOT a post-quantum PAKE. This is a stopgap PAKE with a more complex set of security guarantees. It should only be used in scenarios that fit these guarantees. The first two are typical of any PAKE, the latter two are more particular to this one:
- Passive adversaries cannot learn the session key produced by the PAKE. That is, if an attacker simply observes all messages sent in the protocol, they do not know what the final key is.
- Active (i.e., man-in-the-middle) classical adversaries can make 1 password guess per PAKE execution. If they guess the password correctly, they learn the password and session key.
- Passive quantum adversaries can learn the password. That is, if a quantum adversary is given an execution transcript of the PAKE, they can launch a brute force attack on the password. Because of the structure of the transcript, they will know when their guess is correct. This doesn't reveal the session key, though (as guaranteed in point 1).
- Active quantum adversaries can make an unbounded number of password guesses per PAKE session. If they can successfully brute-force the password in real time, they learn the password and session key.
When to use this PAKE
A user should assume that a password used with this PAKE will eventually get revealed (via point 3). Further, they should assume that it is not a secure key exchange mechanism once quantum computers exist (via point 4).
This PAKE is appropriate if, for example, you are using one-time-use passwords, and you don't intend to keep this PAKE as a long-term solution.
Contributors
The original author of this code is Kevin Lewi (@kevinlewi). To learn more about contributing to this project, see this document.
Acknowledgments
The author would like to thank Michael Rosenberg (@rozbb) for the initial discussions which helped lead to the creation of this library.
License
This project is dual-licensed under either the MIT license or the Apache License, Version 2.0. You may select, at your option, one of the above-listed licenses.