Digital cryptography! This is a subject I've been interested in since taking a class with Prof. Fred Schneider back in college. Articles pop up on Hacker News fairly often that pique my interest and this technique is the result of one of them.
Specifically, this is about Lamport signatures. There are many signature algorithms (ECDSA and RSA come to mind as popular choices) but Lamport signatures are unique because they are formed around a hash function. Many cryptographers believe that, as such, they are immune to attacks made possible by quantum computers.
Here's the long version. I'll give you the short copy without all the parameterization:
- Come up with 2 sets (set 0 and set 1) of 256 random 256-bit numbers. Keep these secret! They're your private key.
- Take the SHA-256 hash of each of your secret numbers. These 512 hashes are your public key.
- Get the SHA-256 hash of whatever document you want to sign
- For each bit
i
of the hash from 0..256: If it is a 0, publish thei
th number from secret set 0. If it is a 1, publish thei
th number from secret set 1. Destroy all unused numbers. - You now have a signature (the 256 random numbers from step 4 corresponding to the bits of the hash from step 3) and a public key (the 512 hashes from step 2).
Because hashes are un-invertible, there is no way other than brute force to forge the secret, random numbers you created in step 1 that would allow an attacker to change your signature.
There are two snags with using this scheme in practice:
- This is a one-time signature. You can't sign anything else with the same public key, because doing so would reveal more secret numbers and potentially compromise your signatures. This is easily solved with a hash tree, which is called the Merkle signature scheme.
- The signatures are huge compared to ECDSA or RSA. Signing an N-bit hash requires N hashes of N bits each... that's around 8kb for signing a 256-bit hash. Fortunately, the security factor for hash functions is better than that for other signature schemes so we need fewer bits to achieve the same security, but the size of the signature itself is still comparatively enormous. Moreover, the fact that it is quadratic in the number of bits of the hash is less than desirable.
The Wikipedia article outlines ways to shorten the private key using a random number generator and compress the public key with a hash list, but no solution for shortening the public signature is published. That's where this article comes in! (cue trumpets)
First, I present an toy algorithm that cannot be implemented for a number of reasons but demonstrates the security proposition. Then, I modify it to make it usable in practice.
Assume you have a 3-bit signature of a document, H3bit(document) = 6
. Pick two random 5-bit values, 12
and 29
, as your private key. Hash each value 2^sigbits + 2 = 2^3 + 2 = 10
times with a perfect random 5-bit oracle called H5bit
:
12 --> 5 --> 24 --> 9 --> 1 --> 15 --> 10 --> 8 --> 11 --> 27
23 <-- 19 <-- 20 <-- 4 <-- 13 <-- 17 <-- 3 <-- 14 <-- 28 <-- 29
The last values, (27, 23)
are your public key. Each possible value of your 3-bit signature has a corresponding index in this chain:
[0] [1] [2] [3] [4] [5] [6] [7]
12 --> 5 --> 24 --> 9 --> 1 --> 15 --> 10 --> 8 --> 11 --> 27
23 <-- 19 <-- 20 <-- 4 <-- 13 <-- 17 <-- 3 <-- 14 <-- 28 <-- 29
Find the pair of values corresponding to your document: [6] = (8, 14)
. By publishing these values, anyone with the public key can verify that (8, 14)
corresponds to the H3bit(x) = 6
since 8
hashed twice is 27
and 14
hashed 7 times is 23
. However, an adversary cannot create a valid signature for another value without inverting one of the hashes. For example, to change the pair to sign the value 7
, the adversary must be able to solve H5bit(x) = 14
for x
in order to produce the pair (11, 28)
. Similarly, to change the pair and sign the value 5
, the adversary must be able to invert H5bit(x) = 8
and produce the pair (10, 3)
. I call this construct a hash ladder because every pair of hash values in the two rows locks each other in place and defines a distinct location on the number line.
Now, we can't actually use this without some modification. Creating a signature in this way for a 256-bit value would require a 257-bit hash function to be executed 2*2^256+2
times just to make the public signature. Not only would one signature take longer to compute than the age of the universe, it isn't secure without a hash function that is a perfect perfect random oracle, and any machine that could actually compute this function would be able to invert hashes by brute force anyway.
To use shorten Lamport signatures with a hash ladder, we need to chop up the hash to be signed into manageable chunks and create a ladder for each. Each ladder needs to be short enough to be both computable and to have a very low probability of having hash collisions anywhere in the ladder itself.
While this can be parameterized to use different ladder chunks and different hash sizes, I present this using 8-bit chunks and 256-bit hashes.
- Take the SHA-256 hash of the document you want to sign
- Split the 256-bit hash of your document into 32 8-bit chunks
- For each chunk, generate a pair of secret random 256-bit numbers. These 64 numbers are your private key.
- Hash each of these numbers 258 times. This final set of 32 pairs of 2 hashes each are your public key. (Note: Use a hash chain and this public key becomes just 256 bits)
- To create your signature, examine each chunk again. Let the value of this chunk be
n
with the range[0, 255]
. There are 2 256-bit numbers of the private key associated with that chunk. Leta
equal the first of these numbers hashedn+1
times. Letb
equal the second of these numbers hashed256-n
times. Publish the result(a,b)
. This pair is your signature for this 8-bit chunk. - Collect up the
32
signatures from each chunk, and you have a32*2*(256/8) = 2kb
signature! This is 4x smaller than the usual Lamport signature.
- Take the SHA-256 hash of the document you want to verify
- Split the 256-bit hash of the document into 32 8-bit chunks
- For each chunk, let the chunk's value from the hash be
V
, the signature pair of numbers be(a, b)
and the corresponding public key pair be(Pa, Pb)
- Hash
a
and count the iterations until it equalsPa
or it has been hashed 256 times. If it was hashed 256 times without reachingPa
, the signature is invalid. Save the number of iterations it took to reachPa
froma
asi_a
. - Repeat step (4) for
b
, saving the number of iterations to reachPb
fromb
asi_b
. - If
i_a != 256-i_b
ori_a != V
, this signature is invalid. - If there are more chunks, check the next chunk starting with step (3)
- The signature is valid if all chunks are signed correctly.
We trade off storage size for computation. Rather than having to compute 256 hashes to verify a 256-bit signature, we now must compute at least 256/8 * 256 = 8192
hashes. However, given that hash functions are much faster than access to main memory, this is likely to be a good tradeoff for moderate chunk sizes.
Specifically, if n
is the bits of the hash function and k
is the bit size of each chunk:
(n/8)*2*(n/k)
bytes is the size of the public keyn/k * 2^k
is the number of hashes that must be computed to verify the key
The usual Lamport algorithm is essentially a special case of k=1
: every group is 1 bit, and the second part of each pair is implied since there is only 1 option.