Crypto++ 5.6.3 Release Candidate available (RC5)

43 views
Skip to first unread message

Jeffrey Walton

unread,
Oct 20, 2015, 8:20:49 AM10/20/15
to Crypto++ Users
Hi Everyone,

We have a new release candidate available at https://www.cryptopp.com/cryptopp563rc5.zip. Here are the checksums:

   $ md5sum cryptopp563rc5.zip
   fc262c405b350f11f36aafa50f4d4752

   $ sha1sum cryptopp563rc5.zip
   3e6ab5e68f88a809d332d14b0dd301a0389cc2ee

   $ sha256sum cryptopp563rc5.zip
   3c345cff42d7d6db1c3eb980132b07e283a6616d450995bb03195499db183f39

We still need to cut-in the RDSEED stuff, but it should be painless based on RDRAND.

This RC also addresses VCUpgrade problems at VS2010 caused by the MSBuild changes (or maybe, more correctly, the deficiencies in VCUpgrade).

-----

The VCUpgrade problems were addressed by providing a vs2010.zip as part of the distribution. Just unpack the ZIP over top the existing files, and the solution and project files will become VS 2010. You can also delete the *dsw *.dsp *.vcproj files.

We were able to clear nearly all the VCUpgrade issues, and 20 of 24 configurations build from the IDE. The remaining 4 must be built from the command line because we can't seem to express the dependency needed to make the machinery work as expected.

The configurations that don't build are the DLL-Import pieces of the Cryptest project. In normal use, the Cryptest/DLL-Import configurations are not usually built, so its not a hardship. The FIPS DLLs build OK; the problem is getting the DLL-Import Cryptest to use the export library.

If you try to perform an VCUpgrade yourself, then the first thing you have to do is delete the Assembly References VS2010 puts in place of dependencies. Then, you should reconstruct the dependencies by hand. The VS2005 projects were modified so linker paths and libraries are present after the VCUpgrade, which should save 8 to 12 failures from Microsoft's decoupling of the projects under MSBuild.

Jean-Pierre Münch

unread,
Oct 20, 2015, 1:07:43 PM10/20/15
to cryptop...@googlegroups.com


Am 20.10.2015 um 14:20 schrieb Jeffrey Walton:
Hi Everyone,

We have a new release candidate available at https://www.cryptopp.com/cryptopp563rc5.zip. Here are the checksums:

   $ md5sum cryptopp563rc5.zip
   fc262c405b350f11f36aafa50f4d4752

   $ sha1sum cryptopp563rc5.zip
   3e6ab5e68f88a809d332d14b0dd301a0389cc2ee

   $ sha256sum cryptopp563rc5.zip
   3c345cff42d7d6db1c3eb980132b07e283a6616d450995bb03195499db183f39

We still need to cut-in the RDSEED stuff, but it should be painless based on RDRAND.

Surprisingly RDRAND caused an additional error for me on VS2015. VS2010 is fine.
I get a LNK2026[1] when trying to build cryptest. This only happens on x86.
The exception seems to be caused by the way exceptions are handled. x64 and ARM have additional data in their binaries apparently that make safe exception handling (safeesh) superfluous.
We didn't get this error until now because all the ASM files we're using are set for x64 assemble only. The x86 assembly is somehow directly incorporated into the source files.
We'll have the same error with RDSEED if we 1:1 patch it in.

As far as fixing goes, the standard proposal is to disable safeesh. This fixes our issues, but may also reduce security. We could as well look into how this was handled in the past with our ASM code and adapt this approach for our RDRAND and RDSEED code (and maybe place it in x64masm.asm?).

As can be seen in salsa.cpp for example we'd have to use the AS2 macro (using __asm{} ) for this approach.

BR

JPM

[1]: https://msdn.microsoft.com/en-us/library/100ezk17.aspx

This RC also addresses VCUpgrade problems at VS2010 caused by the MSBuild changes (or maybe, more correctly, the deficiencies in VCUpgrade).

-----

The VCUpgrade problems were addressed by providing a vs2010.zip as part of the distribution. Just unpack the ZIP over top the existing files, and the solution and project files will become VS 2010. You can also delete the *dsw *.dsp *.vcproj files.

We were able to clear nearly all the VCUpgrade issues, and 20 of 24 configurations build from the IDE. The remaining 4 must be built from the command line because we can't seem to express the dependency needed to make the machinery work as expected.

The configurations that don't build are the DLL-Import pieces of the Cryptest project. In normal use, the Cryptest/DLL-Import configurations are not usually built, so its not a hardship. The FIPS DLLs build OK; the problem is getting the DLL-Import Cryptest to use the export library.

If you try to perform an VCUpgrade yourself, then the first thing you have to do is delete the Assembly References VS2010 puts in place of dependencies. Then, you should reconstruct the dependencies by hand. The VS2005 projects were modified so linker paths and libraries are present after the VCUpgrade, which should save 8 to 12 failures from Microsoft's decoupling of the projects under MSBuild.

--
--
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-user...@googlegroups.com.
More information about Crypto++ and this group is available at http://www.cryptopp.com.
---
You received this message because you are subscribed to the Google Groups "Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cryptopp-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jeffrey Walton

unread,
Oct 20, 2015, 3:29:17 PM10/20/15
to Crypto++ Users

The exception seems to be caused by the way exceptions are handled. x64 and ARM have additional data in their binaries apparently that make safe exception handling (safeesh) superfluous.
We didn't get this error until now because all the ASM files we're using are set for x64 assemble only. The x86 assembly is somehow directly incorporated into the source files.
We'll have the same error with RDSEED if we 1:1 patch it in.

I encountered that when building from the command line using make-rdrand.cmd (and then linking in a test driver program). The fix was to add /safeseh to the X86 builds (and the reason why only %ASFLAGS% includes it). But I did not encounter it once I moved to the Visual Studio IDEs.

Open the cryplib.vcproj (or vcxproj) in a TEXT editor like Notepad++ (and not Visual Studio). Search for "rdrand.asm, and add /safeseh to the Win32 rules (not x64 rules):

  <Tool
      Name="VCCustomBuildTool"
      CommandLine="ml.exe /c /nologo /D_M_X86 /W3 /Cx /Zi /safeseh /Fo&quot;$(IntDir)\rdrand-x86.obj&quot; &quot;$(InputPath)&quot;&#x0D;&#x0A;"
      Outputs="$(IntDir)\rdrand-x86.obj"
  />

It tested OK on VS2005, VS2008, VS2010 and VS2012. I can't test on VS2015 due to Microsoft's expiring trial and and lack of support for the free accounts they require. (I wish the FTC would step in and stop these silly games with "free" companies like Microsoft and Apple engage in).

The information was added to https://cryptopp.com/wiki/RDRAND#MASM.2FMASM64. I plan on adding the RDSEED stuff here, too (unless you want to create a new page).

Jeff
Reply all
Reply to author
Forward
0 new messages