In theory - when there IS a theory! - everything is neat, simple and takes almost no time¹. 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 v.pl 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 spiffy² 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! ↩

Category: Coding

Comments feed: RSS 2.0