Back to academic signature homepage

Troubleshooting compiling Academic Signature in (x/l/k) ubuntu17.10

A workaround is already in place in the current source code packages since nov 8, 2017.

This page is about a flaw that apparently occurred in close coincidence with the rollout of ubuntu Artful Aardvark.
It only occurs in the 64 bit version of the compiler g++, the 32bit version is not affected.

As of November 2017 g++ (Ubuntu 7.2.0-8ubuntu3) 7.2.0 (64 bit version only) can produce faulty object files, if optimization -O2 or -O3 are turned on.
And it does so in Academic Signature's module helpersxx.cpp, affects three instances of slightly differently flavoured pseudorandom functions and alters the outcome of pseudo random functions used in ciphers "flightx", "chimera" and in a key derivation function.
(No, this is not about ambiguous, poorly defined code, I narrowed it down to three affected lines of code in c++. )

The modifications to the output due to invocation of optimization level -O2 and above are reproducible, but doing something other than coded in C++ is not acceptable.
Practically the flaw would break consistency with the output of debug versions (disabled Optimizations), versions of ubuntu 17.04 and older, versions compiled with optimization level below -O2, or the windows versions. For cross platform encrypted communication this is clearly a no go.
So if you recently experienced not being able to decode ciphers sent to you by communication partners, the person with a more recent self compiled installation - compiled with the above mentioned version of g++ with source code downloads from before Nov 8 2017 - should compile again with optimizations restricted to -O1.
I already changed the tarball and the alternative makefile to limit optimization to -O1.

All posted binaries were not affected and produce sound ciphers.
All current source code packages have the workaround in place.

I will look for more elegant workaround than globally limiting optimization, but for the time being, the quickest fix seems to be globally limiting optimization to -O1.
Actually there is no noticeable degradation of efficiency introduced with abandoning -O2 and above.
The improvements in execution speed due to compiler optimization had been marginally at best anyways.