How do I correctly use libsodium so that it is compatible between versions?

I'm planning on storing a bunch of records in a file, where each record is then signed with libsodium. However, I would like future versions of my program to be able to check signatures the current version has made, and ideally vice-versa.

For the current version of Sodium, signatures are made using the Ed25519 algorithm. I imagine that the default primitive can change in new versions of Sodium (otherwise libsodium wouldn't expose a way to choose a particular one, I think).

Should I...

1. Always use the default primitive (i.e. crypto_sign)
2. Use a specific primitive (i.e. crypto_sign_ed25519)
3. Do (1), but store the value of sodium_library_version_major() in the file (either in a dedicated 'sodium version' field or a general 'file format revision' field) and quit if the currently running version is lower
4. Do (3), but also store crypto_sign_primitive()
5. Do (4), but also store crypto_sign_bytes() and friends

...or should I do something else entirely?

My program will be written in C.

0 Answers

Read More

IExpress.exe on Windows 10 is producing an EXE incompatible with Windows XP

Similar to this issue.

I've being using IExpress (included with Windows) for years to package up my bootstrapper EXE and .NET application MSI into a self-extracting installer file. (My app is 32-bit, so I've used the version of iexpress.exe in %windir%/SysWOW64)

I recently moved from Windows 8.1 to Windows 10.

Without changing anything about my code, using IExpress on Windows 10 is resulting in an EXE that won't run on Windows XP (getting "[FileName].exe is not a valid Win32 application").

Using IExpress on Windows 8.1, 8 or 7, it works fine.

Can anyone shed some light or provide a solution??

(I tried copying the iexpress.exe from Windows 8 (file version 11.0.9600.17416) into Windows 10 and using it instead but the same thing happens.)

1 Answers

Answers 1

Yes another reminder that XP is truly over and done with. When I run dumpbin.exe /headers on the EXE file that IExpress generates, I see:

  OPTIONAL HEADER VALUES        ....        10.00 operating system version        10.00 image version         6.00 subsystem version        .... 

The subsystem version number is the first show-stopper, 6.00 is the version number of Vista. That is fixable, you can run Editbin.exe to change it with the /SUBSYSTEM option, XP is 5.01

The operating system and image version is the bigger problem, can't fix that with Editbin.exe. Not actually sure how much attention XP pays to its value, getting 10.00 is very new. I don't have a machine with XP anymore, just try it.

Copying the old version of IExpress.exe is not enough. It uses c:\windows\syswow64\makecab.exe to actually get the job done. I see some cursory evidence that it is the actual source of the EXE header content. Don't just blindly copy that EXE into the windows directory, that's too risky. Keep it separate.

The sane way to go about this is otherwise to keep a bootable copy of XP around, either on its own machine or a VM. You need it anyway to troubleshoot customer problems that are specific to XP. Pay the hassle of still having to support XP forward to the customer and they tend to do the wise and necessary thing a lot quicker. Can't help you with that.

Read More