Some Branching Troubles on Existing V Trees

July 10th, 2018 by Diana Coman

In theory - when there IS a theory! - everything is neat, simple and takes almost no time1. Today's everything started similarly neat and simple with a clear goal that was not meant to take much time: finding a better home for my Keccak implementation.

To clarify the issue here: currently Keccak is part of EuCrypt mainly because at the time of its implementation 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 Arjen (ave1) has released a zero foot print (ZFP) library that is delightfully effective at eliminating bloat. And on top of all this, V itself is moving forward with more clarity and better practices: there shall be a manifest file, there shall be Keccak hashes instead of sha512. Combined, all those developments really point and prod at the simple fact: Keccak both needs and can get a better home now - namely a home as a branch off ave1's zfp tree!

Branching off an existing V tree is meant to be a straightforward task: press the original tree to the desired leaf, add SMG.Keccak, produce new patch, test that it sits indeed at desired place in the tree and it presses fine, write it all up, release and enjoy. But it didn't take long to get into trouble:

  1. To start with, it turned out that current Keccak can not yet use ZFP because its OAEP wrapper requires Interfaces.C and ZFP does not yet support it. Nevertheless, this is noted and added to the README next to the code but it's not in itself a game stopper: the runtime library to be used is anyway specified with the --RTS switch when invoking gprbuild so there is no need to change anything at a later time when ZFP supports Interfaces.C; moreover, the OAEP wrapper is really just a convenience wrapper so it can be removed if the user desires a stripped down pure Keccak in Ada.
  2. Then, vtools and seemed to not want to play nice together and they sputtered all sorts - this was the easy part to solve though as it turned out I had forgotten to chop the vtools branches properly and keep only one set of patches. Thanks to spyked and phf (and via the logs of course), the needed jolt to my memory was provided, the previous log discussion found and linked, the problem solved: as a result, I had again (as I even remembered I used to have at some other point) the spiffy2 vtools working smoothly and producing the desired Keccak-hashed vpatch.
  3. And then it turned out that I can't quite attach my shiny new vpatch to ave1's tree because my vpatch uses Keccak hashes while his other vpatches are still using sha512 and the combination is of course rather unsanitary.
  4. Adding to the above, I also have quite some trouble in finding a way to properly attach my Keccak patch to the current leaf in ave1's simple tree. Since there isn't a manifest file, I can't take the easy route of not even worrying about this issue and simply add the corresponding line for my patch to this file, knowing it'll come neatly after the current leaf. And it turns out that the difficult solution of making sure I change some file changed by the current leaf is also rather dubious because zfp_2_noc.vpatch changes only a few code files that Keccak really has NO business whatsoever in touching *at all*.
  5. A relatively minor issue by comparison with the ones above but still promising to give headache in the future is the fact that current zfp doesn't actually have its own top directory. So where exactly should I plonk smg_keccak folder in there?

What can I do?

  1. There's a reason many people like theories, especially at a safe distance from practice. 

  2. It's Stanislav's term but it fits best here! 

Comments feed: RSS 2.0

6 Responses to “Some Branching Troubles on Existing V Trees”

  1. ave1 says:

    O nice!

    I started the ZFP code when keccak and manifests were still under discussion. I could regrind the whole thing to support keccak and also add a manifest (although this would not need a regrind).

    But, wouldn't the keccak code in a keccak based vtree create a chicken and egg problem? (I know the vtools use a regrind, so maybe this question would be better posed in the forum)

    Another remark, if you use ZFP version 2 (no C library) you also may not be able to use the C library (the C libraries assume that their initialization has run first and some functions depend on this)

  2. Seems to me that there ought to be a legacy-vtron-compatible tree of the keccak vtron, aha, how else to press it.

    And ZFP is really only appropriate for pure-Ada programs -- there is 0 chance that an item like Eulora, where C/CPP libs are linked in, will run on ZFP.

  3. Diana Coman says:

    Good points. Since vtools includes Keccak (it is the same code but it was copy/pasted and plugged into the vtools holes as required), I don't think the circular thing is a problem - this here is an implementation after all, not necessarily the only one.

    So I would say at this moment it's probably best to regrind since the pain will only grow if not. Please follow the dir structure too (i.e. one top dir as per ).

    The above being said, there can certainly be a bit of time for the forum to comment on it too.

  4. Diana Coman says:

    Asciilifeform This is not about Eulora. It's about Keccak implementation and a place for it. What's wrong with the vtools that supports both Keccak and sha?

  5. Right, vtools, but I was speaking generally -- vtools has C routines in it.

    As for hashes -- it has to remain pressable by the old vtrons, or we get ave1's 'chicken problem'.

  6. Diana Coman says:

    How do we get the chicken problem given that vtools already has Keccak so it CAN press a regrind anyway?

Leave a Reply