~ This is part of the EuCrypt series. Start with Introducing EuCrypt. ~
First of all, you'll need V, the republican versioning system, there is no way around this and I won't provide any way around it either. Grab yourself a copy of V and learn to use it or implement your own copy, as you prefer. If you need some help with that, go first through the gentle introduction to V by Ben Vulpes and if you are still stuck after that come and ask intelligent questions in #trilema on irc.
Once you have V in working order, head to my Reference Code Shelf and download the .vpatches for EuCrypt and their signatures. Alternatively, you should be able to get the same from btcbase's mirror of EuCrypt, possibly1 with some other signatures as well if that helps. Press to the .vpatch you want, but make sure you do include the fixes at least for the components you are interested in. Just saying. Then you're ready for building the lib itself.
EuCrypt can be built in 2 main ways:
- as a single, aggregate library, including therefore all the components: mpi, smg_keccak, smg_bit_keccak, smg_rsa, smg_serpent; you'll get one static library with everything, ready to be used; current size of the resulting file is 215K when built with AdaCore's GNAT 2016 and gcc 4.9.4.
- component by component, picking and choosing only what you need; current sizes when built with AdaCore's GNAT 2016 and gcc 4.9.4: mpi 109K; smg_bit_keccak 17K; smg_keccak 42K; smg_rsa 19K; smg_serpent 20K - 31K (depending on level of optimisation chosen). NOTE: smg_rsa uses smg_keccak and mpi!
EuCrypt is written in Ada (Serpent and Keccak components) and C (mpi and rsa components). Therefore you'll need a tool chain that supports multi-language libraries. My personal recommendation is to use AdaCore's GNAT - it is currently the only tool I know to actually work out of the box for everything that EuCrypt needs2 and it includes directly the rather powerful GPRBuild tool3 for automatic builds of multi-language projects of all sorts. Given this lack of alternatives that I could recommend, I'll mirror here the precise version of AdaCore's GNAT that I am currently using and that I recommend you use too for building EuCrypt:
- GNAT GPL 2016 from AdaCore (it already includes GPRBuild)
- sha512sum_gnat-gpl-2016-x86_64-linux-bin.tar.gz.txt
To compile, simply go to the eucrypt folder and run gprbuild. This will build EuCrypt as an aggregate library. To build any separate component, go to its own folder and run gprbuild there.
EuCrypt has been built successfully so far on the following systems:
- CentOS 6.8, AdaCore's GNAT GPL 2016 (gcc 4.9.4)
- Ubuntu 14.04, AdaCore's GNAT GPL 2016 (gcc 4.9.4)
I'll gladly add to the above list any other systems/configurations that I become aware of - just tell me in the comments below what you compiled it on or even better - write it up on your blog and drop me a link in the comments below (a trackback is good too - just make sure it works!).
Note that the building of EuCrypt as a multi-language, C and Ada project should be quite pain-free with gprbuild. However, there is quite a lot of pain at writing code time when you need to interface between the two languages and especially when you need to pass strings and/or pointers. You can see such interfacing in action in Chapter 12 of EuCrypt (the wrapper for using Keccak OAEP + RSA directly from C code) but I fully recommend in any case that you read as well the very clear account of sending array of octets between C and Ada, by ave1. At the moment EuCrypt uses a more basic method to accomplish the same task, namely copying octet by octet an array of characters from Ada to C or from C to Ada, as required. Feel free to change that (as anything else), of course and let me know how it goes - there is no better way of understanding some code than trying to make a meaningful change to it!
hopefully, at some point not that distant into the future ↩
You CAN supposedly use any other version of GNAT, most notably whatever comes with your gcc and/or specific OS distribution but it seems to lag behind for one thing and to be rather prone to trouble due for instance (among other troubles) to various version mismatch between all the different moving parts; so if you DO use a different GNAT and get it to work correctly, please document your work, write it up on your blog and drop me a link - I'll be happy to read it and add it as known working alternative! ↩
This is NEEDED if you want to build eucrypt as a standalone aggregate library! While you CAN build the components separately with gnatmake for instance, you won't be able to build aggregate library with it as gnatmake simply doesn't support this at the moment as far as I'm aware. ↩
Comments feed: RSS 2.0
Hi Diana,
I have been working with the code and came across a few minor points.
(a) I have a patch to use a filedescriptor instead of opening/closing the device (eucrypt-entropy.vpatch plus eucrypt-entropy.vpatch.ave1.sig.
(b) In 'smg_rsa/truerandom.c', the function 'get_random_octets_from' will either return the requested number of bytes, or less when an error occurred. Unfortunately in 'smg_rsa/rsa.c' in the function 'rsa_oaep_encrypt' and in 'smg_rsa/primegen.c' in the function 'is_composite', the 'get_random_octets_from' function is called in a loop. This loop will only finish if the requested number of bytes is available. For fatal errors (like the device not being available, or not open etc.), this will cause an infinite loop.
(c) In 'smg_rsa/primegen.c', the function 'gen_random_prime' does not check the return value of the 'get_random_octets_from' function. Which could result in a prime with a lot of zeros or non random garbage that was already in the buffer (I have not checked if the buffer get reset to zero before).
(d) There seems to be a mismatch between initial spaces and tabs in the files (very minor point). I think the tabstop is set at 2 but I'm not sure this is so in every function.
Arjen
Hey, nice to see eucrypt gets some testing!
a. Why replace rather than add? I get the idea/potential use case where you really want to pass the descriptor everywhere, but I don't see the case where you want to *not* have anything else. Either way, it's certainly perfectly fine for testing, I don't see any problem with it.
b. This is rather by design - an environment without a working source of entropy is one in which eucrypt has no business going ahead with anything really. Do NOT call it with device not open. I suppose if you have a setup in which this sort of problem can occur and does not recover by itself in a while then you might be better off/prefer to call the versions you made indeed.
c. Uhm, how would it check at that point? Random generated is random generated - either you trust the source or you don't call it. There is a place for testing the random source and even that function, sure, but that's not in eucrypt where it calls it really. For the random source it's environment/maintenance basically and for the function itself is at testing stage. Sure, one *could* drop in there some sort of "is this what I had in there before?"-test but that's basically the sort of "we do what we can because we can't do what we need" - in other words I don't see how it actually resolves the trouble if there is indeed trouble.
d. That is likely to be the case indeed. The whole thing does need some cosmetic patch: basically it started first with tabs and then switched everything (apparently NOT everything) to spaces and moreover somewhere mid-way there was a decision to stick to a strict formatting including lines no longer than 80 chars - it's in the logs.
(b) Ok, I get your point. I will have to think about it.
(c) This was related to (b) a bit, where the other functions check if the number of octets as reported by ‘get_random_octets_from’ matched those that where requested, this function does not.
Hmmm, you *are* onto something there re checking the output of get_random_octets_from. There was a change on get_random_octets_from and apparently there are some cases where I did not fully propagate it. I'll have a look.
Thank you!
[...] ave1's gnat is the current cannonical version, I decided to try diana_coman's adacore gnat alone to see if it'd work. This much was as straightforward as I remember, having needed it for [...]
[...] D1 machine runs Adacore's GNAT 2016 and simply switches between ZCX and SJLJ via the --RTS parameter given to [...]
[...] initial GNAT that made it into TMSR and served so far rather well is Adacore's 2016 GNAT GPL, mirrored previously as part of my work on EuCrypt. The mirrored version is compiled with both ZCX and SJLJ run-times, [...]
[...] and install a working GNAT. My choice here for expedience is to use the frozen Adacore version that I'm hosting on this site. Correspondingly, the relevant part of the script grabs it [...]