sunnyg.io

Quantum Computer-Proof Digital Signatures, Part 2 - Merkle Signatures

Sunny Gonnabathula — Sat, 13 Dec 2014 00:00:00 +0000

In my previous post</a>, I went over my implementation</a> of a quantum-computer-proof digital signature algorithm known as the Lamport signature scheme</a>. We also learned of its greatest weakness: the keypairs can only be used once. While we can't change this property of the algorithm, we can mitigate the weakness by chaining multiple Lamport keys together into a Merkle tree</a>.</p>

Keypair Structure</h2>

A Merkle tree is just a tree</a> where each node's value is the hash of its children's values. The top (or root) node has the interesting property of implicitly containing the information of the entire tree since every node's value implicitly contains the values of if it's children.</p>

So with this in mind, we will start by generating a Lamport keypair for every message we may want to sign with this key tree (the variable keyNum</code>). We then generate the hash of each keypair's public key and store these hashes in our tree (along with the keypairs and other useful information like the size</code>, numOfLevels</code> in the tree, and the topHash</code>, which is effectively our key tree's public key).</p>

var MerkleKeyTree = function(keyNum) {
  this.size = keyNum || KEYNUM;
  this._leaves = [];
  this.usedKeyCount = 0;
  var firstRow = [];
  for (var leafNum = 0; leafNum < this.size; leafNum++) {
    var keypair = new LamportKeypair();
    this._leaves.push(keypair);
    firstRow.push(hash(keypair.pubKey));
  }
  this.levels = [firstRow];

  var levels = Math.ceil(Math.log2(this.size));
  for (var i = 1; i <= levels; i++) {
    // for each level in the tree starting w/ 1 above the bottom
    var curRow = [];
    var prevRow = this.levels[i - 1];
    for (var k = 0; k < prevRow.length; k += 2) {
      // for each hash in the previous row
      // hash it and the next hash's values
      var h = hash(prevRow[k] + prevRow[k + 1]);
      curRow.push(h);
    }
    this.levels[i] = curRow;
  }

  this.numOfLevels = this.levels.length;
  this.numOfKeys = this._leaves.length;
  this.topHash = this.levels[this.levels.length - 1][0];
};
</code></pre>
So here's what the Merkle tree in our key tree looks like, with each array containing the hashes of its two child hashes:</p>
</p>
Message Signing</h2>
To use this tree to sign a message, we have to:</p>

Select a keypair (leaf</code>) and use it to generate a signature.</li>
Publish the signature, along with the path of hashes at each level necessary to recreate the topHash</code></li>
</ol>
We must publish the path so that once the user verifies that the Lamport keypair we used was legitimate, they can hash the public key + sibling public key, and continue hashing these hashes + their siblings until they reach the topHash</code>.</p>
MerkleKeyTree.prototype.sign = function(msg) {
  var finalSig = {};
  if (this.usedKeyCount === this.size - 1) {
    throw new Error('This is your last keypair on this tree);
  }
  // select the first unused keypair
  for (var i = 0; i < this.numOfKeys; i++) {
    if (!this._leaves[i].used) {
      var randomKeypair = this._leaves[i];
      var randomKeypairIndex = i;
      break;
    }
  }
  finalSig.keyPairId = randomKeypairIndex;
  finalSig.pubKey = randomKeypair.pubKey;
  finalSig.message = msg;
  finalSig.signature = randomKeypair.sign(msg);
  // create the path of the hashes needed to get from the
    // published keypair to the topHash
  finalSig.path = [];
  var curLevel = 0;
  var idx = randomKeypairIndex;
  while (curLevel < this.numOfLevels) {
    if (idx % 2) {
      finalSig.path.push(this.levels[curLevel][idx - 1])
    } else {
      finalSig.path.push(this.levels[curLevel][idx + 1])
    }
    curLevel++;
    idx = parentIdx(idx);
  }
// publish the signature, set key properties
  finalSig.path[finalSig.path.length - 1] = this.topHash;
  randomKeypair.used = true;
  this.usedKeyCount++;
  return finalSig;
};
</code></pre>
Here's an example signature of a message signed by the key tree above:</p>
</p>
Message Verification</h2>
To verify a signature, we must first verify signature</code> against pubKey</code>, just as we would with a traditional Lamport key. Then, we'll have to hash the pubKey</code> and hash the result (in the right order) with its sibling key's hash, and keep taking the output and hashing it with its sibling in the next level of the key tree until we end up with one, lone hash.</p>
MerkleKeyTree.prototype.verify = function (sigObj) {
  var idx = sigObj.keyPairId;
  var lamport = this._leaves[idx];
  // if this is a valid Lamport signature...
  if (lamport.verify(sigObj.message, sigObj.signature)) {
    // ... calculate the sibling hashes until you reach the topHash
    var h = hash(sigObj.pubKey);
    for (var i = 0; i < sigObj.path.length - 1; i++) {
      var auth = sigObj.path[i];
      if (idx % 2) {
        h = hash(auth + h);
      } else {
        h = hash(h + auth);
      }
      idx = parentIdx(idx); // gets the parent level hash index
    }
    if (h === sigObj.path[sigObj.path.length - 1]) {
      return true;
    }
  }
  return false;
};
</code></pre>
If at the end of this process we end up with the string at the end of our path</code> array (which is also our topHash</code>), we'll know that the key used to sign the message belongs to this key tree and this topHash</code> (which should match up with the topHash</code> of the expected owner and message signer).</p>
In conclusion, with this signature scheme, we've allowed a user to generate one large key tree that can be used to sign arbitrarily many messages (including newer keytrees) while only marginally increasing the signature size. While this can't be used for secretly encrypting messages, in many applications (e.g. authenticating cryptocurrency transactions), a signature scheme is just enough.</p>
I hope both of these posts have shed some light on how wild yet understandable some cryptographic concepts can be. You can always check out my repo here</a> and as always, thanks for reading!</p>



Quantum Computer-Proof Digital Signatures, Part 1 - Lamport Signatures
Sunny Gonnabathula — Sun, 07 Dec 2014 00:00:00 +0000
For my MVP (minimal viable product) project at Hack Reactor</a>, I developed a browser library</a> that implements two quantum-computer-proof digital signature algorithms known as the Lamport</a> and Merkle signature schemes</a>. In this post, I'll be going over the Lamport scheme and how it works.</p>
Keypair Structure</h2>
Unlike keypairs of traditional encryption algorithms, Lamport keys are not mathematically tied to one another nor are they derived from hard-to-solve problems like prime factorization (this is in fact the reason this algorithm is quantum computer-proof: so long as our secure hashing function can't have solving its inverse optimized by quantum computing, we should be safe). Our private key then is simply composed of 256 pairs of 32 byte numbers while the public key is made up of the hashes of each number:</p>
var LamportKeypair = function() {
  this._privKey = [];
  this.pubKey = [];
  this.used = false;

  for (var i = 0; i < 256; i++) {
    var num1 = random32ByteString();
    var num2 = random32ByteString();
    var hash1 = hash(num1);
    var hash2 = hash(num2);

    this._privKey.push([num1, num2]);
    this.pubKey.push([hash1, hash2]);
  }
};
</code></pre>
Message Signing</h2>
To sign a message with this key, we only have to do two things:</p>
Generate a 32 byte (256 bit) hash of the message.
For each bit in the message, publish either the 1st or 2nd random number of that bit's corresponding pair of numbers within our private key.
These steps end up looking like this:</p>
LamportKeypair.prototype.sign = function(msg) {
  var msgHash = hash(msg);
  var signature = [];

  var that = this;
  // this iterates over every bit in a hash string
  // callback takes the bit and its index in the string
  eachBit(msgHash, function(bit, bitIdx) {
    signature.push( that._privKey[bitIdx][bit] );
  });
  return signature;
};
</code></pre>
But wait, if we publish the numbers in our private key, doesn't that defeat the purpose of making it private?</p>
Well yes, and this highlights the usability weakness of this signature scheme: we can only use each keypair once. The workaround for this is to incorporate multiple keys into a Merkle tree, but that's a topic for a later post.</p>
Message Verification</h2>
To verify the message, all we need to do now is check to see that every number in our signature hashes to one of the values in its corresponding pair in our public key:</p>
LamportKeypair.prototype.verify = function(msg, signature) {
  var msgHash = hash(msg);
  var authentic = true;

  var that = this;
  eachBit(msgHash, function(bit, bitIdx) {
    if (hash(signature[bitIdx]) !== that.pubKey[bitIdx][bit]) {
      authentic = false;
    }
  });
  return authentic;
};
</code></pre>
Why This Works</h1>
To be a valid digital signature algorithm, we have to satisfy one main condition (and maybe a few others that I'm forgetting): the public key cannot leak any information about the private key</em>. Since our public key only contains the hashes of these random numbers (and since hash functions can't be run in reverse, that is, from a hash tell us the input), we satisfy that condition and can now know with certainty one thing: the only person who could have published the numbers in the signature and the hashes in the public key is the same person who possessed all of the random numbers of the private key in the first place.</strong></p>
I hope this post has piqued your interest in non-traditional encryption schemes; I have a companion post</a> about how Merkle trees can mitigate the one-time-expiry property of Lamport signatures. If you want to check out my repo, you can find it (and star it hopefully?) here</a>. Thanks for reading!</p>


IP Addressing (and a segue into CJDNS)
Sunny Gonnabathula — Tue, 18 Nov 2014 00:00:00 +0000
In this post, I'll be lightly elaborating on a 5-minute talk I've yet to give to my classmates at Hack Reactor</a>. We'll start with IPv4 addresses, their format and what's known as address exhaustion before going over the advantages to the new IPv6 address format and finishing with an overview into CJDNS</a>.</p>
IPv4</h2>
</p>
IPv4 addresses are composed of 4 sections of 8-bit numbers, giving us an address space of (2^8)^4 addresses, or for those who don't speak in exponentials, a maximum of 4,294,967,296 unique addresses. However, the amount actually addressable to individual devices is far less since many of these are (by convention) inaccessible or reserved for other uses.</p>
For example, some addresses were allocated to some big companies of the 90's, such as Xerox, Apple and Halliburton. Other addresses and address spaces, were allocated for future private use. Two such addresses are http://127.0.0.0 and http://127.0.0.1 and are known as the loopback addresses, only accessible locally on your computer or server (hence the more common URL, http://localhost).</p>
There are some ranges reserved for "private networks," some of which you might recognize as your router's IP address (192.168.0.1, 10.0.0.1 or 172.16.0.0). By giving routers a unique global address (and giving their connected devices a derivative address from one of the three private network address spaces listed above), we've been able to mitigate this address space exhaustion issue and avoid its implications. But considering there may be as many 16 billion internet-connected devices by the end of 2014, even this scheme will have to come to an end.</p>
IPv6</h2>
</p>
The next iteration of IP addressing is known as IPv6 and makes quite a large change to their format. They are composed of 8 groups of 4 hexadecimal characters, giving us an address space of (16^4)^8 == 2^128, or 3.402 e38 addresses. Interestingly enough, this scheme was named in 1995, meaning that this problem was not only forseen almost 20 years ago, but it hasn't reached significant adoption. But this brings me to my next point and what I really want to talk about...</p>
CJDNS</h2>
CJDNS</a> is an open-source, p2p encrypted meshnetting software and protocol whose developers aim make it the backbone of a new, NSA-proof internet (a goal that, while very, very lofty, might actually be accomplished at some point in the future).</p>
Although it's use constitutes a separate, otherwise inaccessible-to-the-rest-of-the-world internet, I included it here in this post because it does something very interesting: it assigns unique IPv6 addresses to all of it's nodes from the get-go.</p>
</p>
On what we know as the World Wide Web, traffic can be encrypted between a browser and server on the presentation layer of the OSI Model using the SSL protocol, which is now used almost everywhere. However, there are some weaknesses with SSL (excluding bugs</a> in some of its various implementations), namely the required existence of trusted third-parties.</p>
Rather than resort to this layer for encrypting traffic, CJDNS operates and encrypts on the IP layer, just above the two layers responsible for actually carrying and delivering internet traffic. In effect, CJDNS completely hijacks and rewrites the book on how IP-layer traffic and routing work and the responsibilities they should inherit.</p>
What's even more interesting is the fact that the addresses themselves are the hash of the public keys used to encrypt the packets sent between any two nodes. This means that you can always be certain that the address you are communicating with is responsible for the encryption of the traffic you receive from them and that the traffic has not been man-in-the-middled; who that user is and whether or not you can trust them is unfortunately a completely different question.</p>
I'm going to end this post here, but will continue this line of thought in another post in the near future, and will hopefully be connected to its most popular intranet known as Hyperboria; if so, I'll be sure to leave a tutorial for getting started with this super-cool software.</p>

sunnyg.io

Quantum Computer-Proof Digital Signatures, Part 2 - Merkle Signatures

Message Signing</h2> To use this tree to sign a message, we have to:</p>

Quantum Computer-Proof Digital Signatures, Part 1 - Lamport Signatures

Message Verification</h2> To verify the message, all we need to do now is check to see that every number in our signature hashes to one of the values in its corresponding pair in our public key:</p>

IP Addressing (and a segue into CJDNS)