Older blog entries for randombit (starting at number 19)

I recently packaged botan for Windows using InnoSetup, an open source installation creator. Overall I was pretty pleased with it - it seems to do everything I need it to do without much of a hassle, and I'll probably use it in the future if I need to package other programs or tools for Windows.

After I got the basic package working, a nit I wanted to deal with was converting the line endings of all the header files and plain-text documentation (readme, license file, etc) to use Windows line endings. While many Windows programs, including Wordpad and Visual Studio, can deal with files with Unix line endings, not all do, and it seemed like it would be a nice touch if the files were not completely unreadable if opened in Notepad.

There is no built in support for this, but InnoSetup includes a scripting facility (using Pascal!), including hooks that can be called at various points in the installation process, including immediately after a file is installed, which handles this sort of problem perfectly. So all that was required was to learn enough Pascal to write the function. I've included it below to help anyone who might be searching for a similar facility:

   LF = #10;
   CR = #13;
   CRLF = CR + LF;

procedure ConvertLineEndings();
     FilePath : String;
     FileContents : String;
   FilePath := ExpandConstant(CurrentFileName)
   LoadStringFromFile(FilePath, FileContents);
   StringChangeEx(FileContents, LF, CRLF, False);
   SaveStringToFile(FilePath, FileContents, False);

Adding the hook with AfterInstall: ConvertLineEndings caused this function to run on each of my text and include files.

Syndicated 2009-11-23 23:51:23 from Jack Lloyd

SSE2 Serpent on Atom N270: twice as fast as AES-128

On the Intel Atom N270 processor, OpenSSL 0.9.8g's implementation of AES-128 runs at 25 MiB per second (CBC mode, using openssl speed). In contrast, the Serpent implementation using SSE2 I described last month runs at over 60 MiB per second in ECB mode (2.4x faster) and 48 MiB per second in CTR mode (1.9x faster).

Syndicated 2009-10-21 06:11:40 from Jack Lloyd

Programming trivia: 4x4 integer matrix transpose in SSE2

The Intel SSE2 intrinsics has a macro _MM_TRANSPOSE4_PS which performs a matrix transposition on a 4x4 array represented by elements in 4 SSE registers. However, it doesn't work with integer registers because Intel intrinsics make a distinction between integer and floating point SSE registers. Theoretically one could cast and use the floating point operations, but it seems quite plausible that this will not round trip properly; for instance if one of your integer values happens to have the same value as a 32-bit IEEE denormal.

However it is easy to do with the punpckldq, punpckhdq, punpcklqdq, and punpckhqdq instructions; code and diagrams ahoy.

continued »

Syndicated 2009-10-08 21:53:12 from Jack Lloyd

The Case For Skein

After the initial set of attacks on MD5 and SHA-1, NIST organized a series of conferences on hash function design. I was lucky enough to be able to attend the first one, and had a great time. This was the place where the suggestion of a competition in the style of the AES process to replace SHA-1 and SHA-2 was first proposed (to wide approval). This has resulted in over 60 submissions to the SHA-3 contest, of which 14 have been brought into the second round.

Of the second round contenders, I think Skein is the best choice for becoming SHA-3, and want to explain why I think so.

continued »

Syndicated 2009-10-08 19:22:12 from Jack Lloyd

Speeding up Serpent: SIMD Edition

The Serpent block cipher was one of the 5 finalists in the AES competition, and is widely thought to be the most secure of them due to its conservative design. It was also considered the slowest candidate, which is one major reason it did not win the AES contest. However, it turns out that on modern machines one can use SIMD operations to implement Serpent at speeds quite close to AES.

continued »

Syndicated 2009-09-09 19:02:08 from Jack Lloyd

Inverting Mersenne Twister's final transform

The Mersenne twister RNG 'tempers' its output using an invertible transformation:

unsigned int temper(unsigned int x)
   x ^= (x >> 11);
   x ^= (x << 7) & 0x9D2C5680;
   x ^= (x << 15) & 0xEFC60000;
   x ^= (x >> 18);
   return x;

The inversion function is:

unsigned int detemper(unsigned int x)
   x ^= (x >> 18);
   x ^= (x << 15) & 0xEFC60000;
   x ^= (x << 7) & 0x1680;
   x ^= (x << 7) & 0xC4000;
   x ^= (x << 7) & 0xD200000;
   x ^= (x << 7) & 0x90000000;
   x ^= (x >> 11) & 0xFFC00000;
   x ^= (x >> 11) & 0x3FF800;
   x ^= (x >> 11) & 0x7FF;

   return x;

This inversion has been confirmed correct with exhaustive search.

This is more a note to my future self than anything else; I'm cleaning out my ~/projects directory, and I can either publish this somewhere or check it into revision control (well, actually the contents of this blog are also in revision control, but no matter).

Syndicated 2009-07-21 20:40:01 from Jack Lloyd

Isn't Autoconf Supposed To Be, Well, Automatic?

Wherein I complain about things that annoy me.

While attempting to build Carrier:

$ ./configure
[many tests run, taking several minutes]
GtkSpell development headers not found.
Use --disable-gtkspell if you do not need it.
$ ./configure --disable-gtkspell
[many tests run, taking several minutes]
GStreamer development headers not found.
Use --disable-gstreamer if you do not need GStreamer (sound) support.

And iterate that six times. Would it be so hard to just carry on and inform the user that some things won't be built because the headers were not found? Without an explicit --enable-blah request, these should not be hard errors (well, IMO).

Syndicated 2009-06-22 19:04:00 from Jack Lloyd

CVE Id Assigned for GNU Classpath Vulnerability

The error in the GNU Classpath PRNG that I described last month has been assigned an identifier in the Common Vulnerabilities and Exposures list: CVE-2008-5659.

Unfortunately a new version of Classpath with a fixed PRNG still remains to be released, so it seems I'm going to have to sit on the demonstration code showing how to derive DSA private keys for a while longer. At some point it would be nice to also verify that RSA and DH keys can also be compromised, perhaps with a sexy little app that compromises SSL/TLS sessions or something along those lines, but I am currently suffering a shortage of round tuits.

Syndicated 2009-01-21 17:18:55 from Jack Lloyd

Optimizing Forward Error Correction Coding Using SIMD Instructions

Forward error correction (FEC) is a technique for handling lossy storage devices or transmission channels. A FEC code takes k blocks of data and produces and additional m blocks of encoding information, such that any set of k of the blocks is sufficient to recover the original data. One can think of RAID5 as a FEC with arbitrary k and m fixed at 1; most FEC algorithms allow wide latitude for the values that can be sent, allowing the code to be adjusted for the reliability expectations and needs of the particular channel and application. For instance, the Tahoe distributed filesystem splits stored files using k of 3 and m of 7, so as long as at least 30% of the devices storing the file survive, the original file can be recoved.

continued »

Syndicated 2009-01-19 22:35:51 from Jack Lloyd

On Syllable's /dev/random

Inspired by the recent FreeBSD arc4random vulnerability, I've been taking a look at the random number generators used by various libraries and operating systems. So far, problems in the JUCE C++ library and in the GNU Classpath PRNG have been identified. (I also checked out Mozilla's NSS, but did not spot any major flaws in that implementation.)

Syllable is a desktop OS based on AtheOS that provides what seems like a pretty decent desktop experience along with POSIX APIs and the GNU toolchain. My initial interest in the project was to get it installed under KVM and port my project botan to it.

read more »

Syndicated 2008-12-09 18:20:36 from Jack Lloyd

10 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!