site: www.imperialviolet.org
Real-world measurements of structured-lattices and supersingular isogenies in TLS
https://www.imperialviolet.org/2019/10/30/pqsivssl.html [www.imperialviolet.org]
2019-10-30 21:45
tags:
benchmark
browser
crypto
networking
quantum
security
This is the third in a series of posts about running experiments on post-quantum confidentiality in TLS. The first detailed experiments that measured the estimated network overhead of three families of post-quantum key exchanges. The second detailed the choices behind a specific structured-lattice scheme. This one gives details of a full, end-to-end measurement of that scheme and a supersingular isogeny scheme, SIKE/p434. This was done in collaboration with Cloudflare, who integrated Microsoft’s SIKE code into BoringSSL for the tests, and ran the server-side of the experiment.
Because optimised assembly implementations are labour-intensive to write, they were only available/written for AArch64 and x86-64. Because SIKE is computationally expensive, it wasn’t feasible to enable it without an assembly implementation, thus only AArch64 and x86-64 clients were included in the experiment and ARMv7 and x86 clients did not contribute to the results even if they were assigned to one of the experiment groups.
Also: https://blog.cloudflare.com/the-tls-post-quantum-experiment/
source: green
Username (and password) free login with security keys
http://www.imperialviolet.org/2019/08/10/ctap2features.html [www.imperialviolet.org]
2019-08-11 23:45
tags:
auth
security
web
Most readers of this blog will be familiar with the traditional security key user experience: you register a token with a site then, when logging in, you enter a username and password as normal but are also required to press a security key in order for it to sign a challenge from the website. This is an effective defense against phishing, phone number takeover, etc. But modern security keys are capable of serving the roles of username and password too, so the user experience can just involve clicking a login button, pressing the security key, and (perhaps) entering a locally-validated PIN if the security key doesn’t do biometrics. This is possible with the recently released Chromium 76 and also with Edge or Firefox on current versions of Windows.
That begs the question: what’s the difference between a PIN and a password? On the surface: nothing. A security key PIN is an arbitrary string, not limited to numbers. (I think it was probably considered too embarrassing to call it a password since FIDO’s slogan is “solving the world’s password problem”.)
CECPQ2
http://www.imperialviolet.org/2018/12/12/cecpq2.html [www.imperialviolet.org]
2018-12-15 19:11
tags:
crypto
networking
quantum
security
vapor
CECPQ1 was the experiment in post-quantum confidentiality that my colleague, Matt Braithwaite, and I ran in 2016. It’s about time for CECPQ2.
CECPQ2 will be moving slowly: It depends on TLS 1.3 and, as mentioned, 1.3 is taking a while. The larger messages may take some time to deploy if we hit middlebox- or server-compatibility issues. Also the messages are currently too large to include in QUIC. But working though these problems now is a lot of the reason for doing CECPQ2—to ensure that post-quantum TLS remains feasible.
Security Keys
https://www.imperialviolet.org/2018/03/27/webauthn.html [www.imperialviolet.org]
2018-04-06 15:31
tags:
auth
browser
crypto
hardware
networking
security
web
Not to be confused with a previous post of the same name.
The FIDO Javascript API is not the future, however. Instead, the W3C is defining an official Web Authentication standard for Security Keys, which is commonly called by its short name “webauthn”. This standard is significantly more capable (and significantly more complex) than the U2F API but, by the end of 2018, it is likely that all of Edge, Chrome, and Firefox will support it by default.
Testing Security Keys
http://www.imperialviolet.org/2017/10/08/securitykeytest.html [www.imperialviolet.org]
2017-10-09 21:23
tags:
auth
crypto
hardware
security
In essence, the U2F spec only contains three functions: Register, Authenticate, and Check. Register creates a new key-pair. Authenticate signs with an existing key-pair, after the user confirms physical presence, and Check confirms whether or not a key-pair is known to a security key.
Maybe Skip SHA-3
https://www.imperialviolet.org/2017/05/31/skipsha3.html [www.imperialviolet.org]
2017-05-31 18:58
tags:
crypto
development
hash
security
standard
Thus, by the time it existed, it was no longer clear that SHA-3 was needed. Yet there is a natural tendency to assume that SHA-3 must be better than SHA-2 because the number is bigger.
AES-GCM-SIV
http://www.imperialviolet.org/2017/05/14/aesgcmsiv.html [www.imperialviolet.org]
2017-05-25 06:19
tags:
crypto
networking
paper
security
standard
AES-GCM with some forgiveness. It uses the same primitives as AES-GCM, and thus enjoys the same hardware support, but it doesn’t fail catastrophically if you repeat a nonce. Thus you can use random, 96-bit nonces with a far larger number of messages, or withstand a glitch in your nonce distribution scheme.
So it’s important to emphasise that AES-GCM-SIV (and nonce-misuse resistant modes in general) are not a magic invulnerability shield.
CFI directives in assembly files
https://www.imperialviolet.org/2017/01/18/cfi.html [www.imperialviolet.org]
2017-01-22 01:31
tags:
c
compiler
cpu
development
programming
Adding Call Frame Information (CFI) to assembly to aid debugging.
CECPQ1 results
https://www.imperialviolet.org/2016/11/28/cecpq1.html [www.imperialviolet.org]
2016-11-30 21:16
tags:
browser
crypto
networking
quantum
security
Our second goal was to measure the feasibility of deploying post-quantum key-agreement in TLS by combining NewHope with an existing key-agreement (X25519). We called the combination CECPQ1.
It’s feasible, but not necessary today. Experiment concluded.