With the advent of quantum computing and quantum cryptanalysis algorithms, the mathematical foundations on which the cryptographic protocols in use today are based have been questioned, as they can easily be circumvented and violated by quantum computers.
While waiting for the creation of quantum computers that work at full capacity, and to protect network communications from "Harvest Now, Decrypt Later" attacks, the cryptographic community is working on post-quantum cryptography algorithms, which work on the traditional computers we use today, but are resistant to future attacks by quantum computers.
One of these algorithms is SPHINCS+, a stateless hash-based signature scheme which serves as the basis for the FIPS 205 specification.
An experimental version of SPHINCS+ (currently only providing the slh_dsa_sha2_128s version of the algorithm) is available inside BoringSSL, which Swift Crypto embeds. @ptoffy and I have created a PoC fork of Swift Crypto which provides a SPHINCS+ Swift API based on these experimental functions, offering a similar interface to RSA and other primitives of the library. We also added testing against other libraries and Known Answer Tests (KAT) provided by the SPHINCS team. The fork of Swift Crypto with the SPHINCS+ API is available (for educational and experimental purposes) at SPHINCS+ by fpseverino · Pull Request #2 · fpseverino/swift-crypto · GitHub.
JWTs use cryptographic algorithms to ensure integrity and authenticity of the data they are transporting and are a prime example of standard which can easily be tampered with using quantum based technology. That’s why, to test out the API in a real life environment, we created a fork of Vapor’s JWTKit, which already relied on Swift Crypto, and added functionality to sign and verify quantum secure JWTs using SPHINCS+. The source code for this fork is available at Sphincs+ by ptoffy · Pull Request #1 · ptoffy/jwt-kit · GitHub.
While this is all still experimental, primarily because the FIPS specification is not complete yet and the BoringSSL APIs are still prone to change, we hope this can serve as an example to get closer to normalising quantum secure algorithms.
Depending on the source, quantum computers capable of breaking RSA and ECC are 10 to 20 years away, so we have the time to battle test these new schemes.
Although we should start using them as soon as possible, because of "Harvest Now, Decrypt Later" attacks, where attackers collect today's encrypted data and retain it until they acquire a quantum computer that can decrypt it.
Regarding the downsides, SPHINCS+ in particular has fairly small keys but huge signatures (no less than 8 kB), but it has the advantage of being based on the secure cryptographic hash functions we already use, whereas other post-quantum protocols are based upon new algorithms that are still being studied.
Algorithms that are still unproven, so might have vulnerabilities;
They have small keys, perhaps making them easier to break.
What the practical problems with large signatures are, I am not sure. I assume this is a one time thing per session/handshake? Then the 8kB can probably be forgiven. Although if these increase the size of tokens, and tokens get resend with every request...
I think it would be nice if these are added as "experimental" to Swift-Crypto or JWT. Then I can use them in low stakes environments, so we can build up experience.
What I should have said about the SPHINCS+ keys is that they are fairly small compared to RSA and especially to other PQC schemes, but they actually offer up to AES-256 level of security.
Obviously, a good post-quantum algorithm should provide at least an equal level of security compared to the ones we use today, in addition to quantum security.
Regarding the signature size, it's exactly as you said.
And of course, I'm also all for adding them as experimental to Swift Crypto!