Routes to Keccak in esthlos-v

Posted 2018-07-08

For reasons amply put in the logs, esthlos-v needs a hashing mechanism, and the standard is Keccak. How can Keccak be attached to the Common Lisp esthlos-v? Really, it comes down to:

  1. Call out to a pre-existing Keccak implementation; or
  2. Write a Keccak implementation for Common Lisp.

Let's consider the options.

Option 1: Call out to a pre-existing Keccak implementation

The only Republican-signed Keccak implementation is smg-keccak, a piece of the EuCrypt library by Diana Coman. How could the smg-keccak be incorporated into esthlos-v? Well, again, there are two options:

  1. Make a new patch with esthlos-v_genesis and some node of the EuCrypt tree as parents.
  2. Build EuCrypt, rip out the non-Keccak code, and patch this code on to esthlos-v.

To 1: Some trouble with the smg-keccak patching prevents simply selecting a subset of the EuCrypt patchset to build only smg-keccak. Either the majority of EuCrypt must be pulled in, or a new patch must be created off of the smg-keccak branch to correct the trouble. I want esthlos-v to be as small1 and simple2 as possible, so pulling in all of EuCrypt is off the table. Creating a trivial new patch, though, is feasible; let's keep this in the back of our minds for now.

To 2: The trouble with this method is how it drops the history built into the EuCrypt smg-keccak patchset, introducing a heap of problems. For instance, dropping the history renders the best resource for understanding the code, Diana's excellent posts, a pain to match to the code. Basically, this approach smells rotten, and will not be pursued.

Details of smg-keccak incorporation aside, what would follow from said incorporation? smg-keccak is written in Ada, so the user of esthlos-v would need a working Ada build environment. If understanding of the code is desired, a working understanding of Ada would be needed as well. Besides, calling out to a common library is a flavor of dynamic soup, to be avoided when possible.

Outside of Ada, a quick search revealed an already existing Keccak for Common Lisp, written by some dweeb.3. Of course, to be signed, it must be deloused and understood, so while it can serve as a useful reference, it can be used as only that: a reference towards a new implementation.4

Option 2: Write a Keccak implementation for Common Lisp

The pluses of having a Common Lisp Keccak are mostly obvious. The use of a single language simplifies things, cutting down on both the requirements needed to get the thing running5 , and the knowledge needed to see how the thing works.

What about the downsides? Well, really the significant downside is the time and effort required to understand the operation of Keccak and implement it. But if smg-keccak was to be pulled into esthlos-v, then that would required a patch, which would need to be signed,6 and so the effort of understanding is unavoidable.7

So in the large, while the incorporation of smg-keccak into the esthlos-v might be the faster and less wasteful option, neither route to the incorporation outweighs the costs. Destroying the vtree structure creates the the "wtf is this, how does it work, and how did it come to be" problem, and branching off the EuCrypt tree still pulls in Ada as a dependency. The most natural cut, then, appears to be a Common Lisp Keccak.

Comments from the Lordship appreciated.

  1. "The practice is pervaded by the reassuring illusion that programs are just devices like any others, the only difference admitted being that their manufacture might require a new type of craftsmen, viz. programmers. From there it is only a small step to measuring "programmer productivity" in terms of "number of lines of code produced per month". This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger." -Dijkstra []
  2. fits-in-head is a hard requirement []
  3. Warning: the choice of font may melt eyeballs []
  4. And there are those of us stuck in USGland, where the licensing of the thing is an issue. []
  5. aka the number of things which can break []
  6. An outstanding question of mine is whether signing a vpatch is a statement about the transformation of code outlined in the patch, or the state of the codebase once the patch is applied. []
  7. As usual. []

3 Responses to “Routes to Keccak in esthlos-v”

  1. [...] esthlos It was not made for those who sell oil or sardines... « Routes to Keccak in esthlos-v [...]
  2. [...] weeks ago, I determined that the writing of a Republican1 Common Lisp Keccak is the best path forward for esthlos-v. So [...]
  3. [...] there simply was no better place for it. But meanwhile phf integrated Keccak into his vtools, esthlos is actively searching for the best way to use Keccak hashes as part of his own V implementation and [...]

Leave a Reply (USE HTML! Space not preserved!)