Modernization of Crypto++

[Jean-Pierre Münch]

Hey Guys,

I'm currently working on something that might interest you:
The modernization of Crypto++ !

I'm accumulating source code and sometimes writing some of my own in preparation of integration into the library.

The current new things (that have yet been finished) are:
- Threefish, with tweak as part of key
- RSA signature with PKCS#1 v2.0
- HMAC support for SHA3 and co.

Yet unfinished modules:
- Threefish as a whole new class of tweakable block ciphers (ay result in zeroing the tweak for classic ciphers/modes)
- scrypt, there're still some design issues I've to deal with, but this is rather sooner than later finished.

Stuff that may cause some problems:
- Skein (as I would like to use the original files, which are unfortunaly multiple files, need to clarify this at time with WeiDai)
- Fortuna (Submitted the request for allowance of usage at codeproject, after permission has been granted there's still some work to do to bring this to Crypto++)

Post as reply if you think something needs to be added to the list.

BR

JPM

[Ruben De Smet]

On 23/12/14 15:47, Jean-Pierre Münch wrote:
> Post as reply if you think something needs to be added to the list.

I'd like to re-request NTRU.

For this, you'll need a separate European and a patent-encubered version
of NTRU though, because NTRU is still patented.

Ruben

[Zooko O'Whielacronx]

I request BLAKE2! :-)

https://blake2.net/

(Disclosure: I'm one of the authors.)

--Zooko

[Mouse]

And I request a separation between AES (limited to 128-bit blocks) and Rijndael (with block size configurable). :-)

Oh, and inclusion of FHMQV, so I don't need to fetch it every time a new release comes out. :-)

And including my Mac OS X patches would be nice too. :-)

--
--
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.

--

Regards,
Mouse

[Jean-Pierre Münch]

Hey guys,

thank you for your responses.
I will now tell you my evaluation:

NTRU: I looked it up and actually found an open-source implementation. But the problem with it though is that the guys providing the implementation (I believe they are the inventors) want money for commercial applications. Crypto++ is a library where every single source file is placed in the public domain and the whole library is under boost-license. I don't think we can incorporate NTRU. But once I finished all the stuff (which may take me some months) i'll contact Wei Dai and ask wether NTRU is possible.

BUT: If everything you wan't is Post-Quantum PK-encryption i'll see what's possible concerning McEliece.

Blake: It got the same problems as Skein does: it's multiple files large.From a license point of view BLAKE won't pose any problems and I think I'll incorporate it right after skein.

Inclusion of FHMQV shouldn't pose any problems and will be done.

OS X patches will be included if and only if they don't produce incompabilities with other platforms (linux & windows). I'll test windows and once finished I'll post the whole library in the wiki (and here) and someone needs to confirm me that compilation works under linux.

Rijndael is something I proposed myself in a paper (at school) I wrote once. The problem with Rijndael though is that i'm not sure wether this is possible. I'll dig more into the implementation of Rijndael and compare with specifications (I got them somewhere) and see what's possible. The Problem might still remain that I don't know (yet) how to code using assembler language and crypto++ got it's own "derivat" of ASM. Conclusion: I can't promise anything but if (for me) possible I'll do it.

I'm currently at the point were I set everything up (including some tests) and fixed everything that Visual Studio's static code analysis found.
Next step will be to integrate the finished stuff and set up tests (with test vectors) of the stuff I claimed finished.

If anyone want to participatein this whole modernization process contact me and we'll find productive ways of cooperation.

BR

JPM

[Mobile Mouse]

Jean-Pierre,

Thank you for your efforts!

Re. Mac OS X patches - they don’t introduce any incompatibility, especially because most of them are contained in the GNUmakefile, and are isolated by “ifeq … endif”.

Re. Post-Quantum - I think McEliece would work just fine, especially if the “no key minimization” approach is taken (as mentioned in the Wiki I referred to)...

Thanks!

[Jeffrey Walton]

You might want to grab this, too: http://www.cryptopp.com/wiki/PEM_Pack. Its purely utility related, but its helpful, especially if you are interop'ing with OpenSSL. I released it under the same license as the Crypto++ library.

I can also change FHMQV's license if needed (it should be the same terms as Crypto++, but I don't recall).

[Jeffrey Walton]

We also have a few patches for cross-compiling. You can find them at: http://www.cryptopp.com/wiki/Category:Cross_Compile.

The cross-compiling pages are missing two pages on Windows RT and Windows Phone. I have the procedures and patches, but I have not written them up yet.

I asked Wei about incorporating the cross-compile stuff a couple of times (like what's his idea of the best way to approach cross-compilation), but I did not get a reply.

Also, you might want to reach out to Wei about it since he might be willing to incorporate this into the official Crypto++ release.

Jeff

On Tuesday, December 23, 2014 9:47:21 AM UTC-5, Jean-Pierre Münch wrote:

[Jean-Pierre Münch]

Hey everyone,

Happy New Year. (2015)

First of all:
I've got some things finished.
The current state of the library is zipped and appended.
Please also read the changelog (the other appended file).
Highlights of this version of Crypto++ (we'll discuss shorty about the naming):
-Inclusion of the patch for HMAC, HMAC now works for SHA-3 and Ciphers without BlockSize / BLOCKSIZE-constant
-Changed ECIES, you can now use other hash-functions than SHA-1 for keystream generation.
-Added framework for Tweakable Block Ciphers, they're a specialization of Block Ciphers with tweakable properties
-Implemented Threefish with all three key sizes as tweak able block ciphers
-Implemented Skein on top of Threefish

Known Issues:
-Variable block sizes are not supported by Crypto++ and if you use them you can't use ayn of the "good" modes (CTR & co) ->  no generic Threefish, only Threefish_256,..

Now to the naming:
I propose: Crypto++ 5.7.0 beta 1 (for current release)
and incrementing the value after beta to reflect number of releases already done

@jeffrey:
I'm not sure if I will incorporate the Cross-Compile patches.
I will look into them and decide afterwards.
Concerning the license of FHMQV: please place the implementation in the public domain. All files in Crypto++ are placed in the public domain.
I think I will incorporate the PEM-Pack, maybe even the ECIES Bouncy-Castle-Pack.

@Mouse:
I've already patched the cpu.h file but somehow I get errors as I try to patch the GNUMakefile. Could you please post the 5.6.2 makefile with your changes applied?
Concerning PQ-Crypto: This is one of the last things I will include. But if I include McEliece, I'll use Kobara-Imai's GAMMA-Conversion (http://www.e-reading.link/bookreader.php/135832/Post_Quantum_Cryptography.pdf, page 142) with a nice decoding method I found in another paper, they use it for HyMES (http://www.cayrel.net/IMG/pdf/hymes_cw_buescher_meub.pdf).

Current roadmap looks like this:
- Redesign PBKDF interface for long-term compability with PHC winners
- apply various patches to Crypto++ (PEM, ...)
- implement BLAKE2 family

So there are some questions open I need to ask you:
- Do you want Skein-MAC?
- Do you want BLAKE and BLAKE2 or just BLAKE2 ?

And I've got some work (sorry for that) for you:
Please test the implementation of Threefish and Skein for Correctness on Big-Endian-Platforms as I don't have access to any of them.
Test vector check routines are appended.
Please also test my PKCS 1 v2 RSA signature scheme implementation for correctness.

BR

JPM

[Jeffrey Walton]

> Now to the naming:
> I propose: Crypto++ 5.7.0 beta 1 (for current release)

You might want to reconsider this. You should probably leave the Crypto++ name with Wei and come up with something new for your fork. At minimum, it will avoid confusing users. Changing the name also seems to be customary. For example, the recent fork of LibreSSL from OpenSSL.

I can just imagine it now: a user says "I'm using Crypto++ 5.7" when the library is officially at 5.6.2 or 5.6.3. They won't understand the library was forked and the name was borrowed.

Jeff

[David Irvine]

What about go the whole hog and call it crypto++14 and modernise the library completely to handle rvalue moves generic lambdas (to improve readability of the vast template system) etc. where speed increases and further safety would be included. Its a larger proposition but would differentiate it enough? 

crypto++14-XX where XX is the version etc.

--

--
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.

--

David Irvine

twitter: @metaquestions

blog:  http://metaquestions.me

[Jeffrey Walton]

> What about go the whole hog and call it crypto++14

I get what you are saying, but I think it would confuse users. I think its best to avoid the confusion.

I was thinking Crypto++ NG but I struck it because it has a propensity to confuse users.

And leaving the name with Wei seems like the right thing to do. The guy was good enough to give the source code away under a very permissive license. Don't try and take his name, too.

(Plus, someone else already hijacked the name. See the related links page at http://www.cryptopp.com/wiki/Related_Links).

Jeff

[David Irvine]

On Fri, Jan 2, 2015 at 2:04 PM, Jeffrey Walton <nolo...@gmail.com> wrote:

And leaving the name with Wei seems like the right thing to do. The guy was good enough to give the source code away under a very permissive license. Don't try and take his name, too.

Agreed, his contribution is massive and should not be lost though, so nice to recognise him in any further works. You are correct though, through attribution and not hi-jacking. I hope if he reads this he will not think this is abandonment but progression and a good thing. You yourself Jeffrey have done a mammoth amount in the library as well helping many people. I imagine the main thing is the keep the community healthy and moving forwards where it upgrades, accepts patches etc. My only worry (apart from offending) is the "eyes on" for all patches. 

In that I think I would be happy to get a CI set up to check commits against any known vectors etc. if we can identify enough of them. Probably with the addition of a more thorough test suite and coverage analysis. It would be terrible if anything leaked info or worse if the library did accept patches easier. The commit access would have to be very well managed I would imagine.  

[Jeffrey Walton]

> Please test the implementation of Threefish and Skein for Correctness on
> Big-Endian-Platforms as I don't have access to any of them.
> Test vector check routines are appended.

You should be able to test these yourself. GCC makes available a test farm at https://gcc.gnu.org/wiki/CompileFarm. The HPPA is big endian iron.

You qualify to use the farm because your fork is free software.

To facilitate the login account, you might want to document your efforts on the Crypto++ wiki. The GCC folks want a URL for the project and your contributions.

You might also qualify for the other projects, like GNU Herd and Snakebite (listed on the GCC Farm page).

Jeff

[Jean-Pierre Münch]

Hey Everyone,

I think some of you were confused because of my naming convention.
I'm sorry for that.
At it's current state this is just a fork and so I recognize that choosing this name was a bad decision.
The idea behind the name was that I was pretty sure, that once I accumulated enough new algorithms I'd send it to Wei Dai and he would incorporate this into official Crypto++.
As of now i propose "CryptoJPM 5.7.0 beta1" to make sure there's no confusion that this is a fork.
AND: This code will be publicely available, but I won't recommend using it in a production environment until I contacted Wei Dai.

@david:
Modernization to c++14 isn't an option as I'm using VS2012 to make the changes and it lack support for c++14.
If I'd go for c++14 it feels like ONLY GCC 4.9.X would be able to compile.
That's the wrong way.
In my opinion, even more considering this fork has the aim to be incorporated into Crypto++ and result (hopefully) in Crypto++ 5.7.0 .

@Jeff:
Thank you for the advice.
This sort of extensive testing will be done after I've finished enough code to be able to say: "Now it's time to propose this to Wei Dai".
I'll contact these projects as soon as (at least) scrypt is finished, BLAKE2 is implemented and maybe Argon (because the idea sounds pretty good)is implemented.
Then I'll still have to figure out how to build on Linux/Debian/(whatever) and run tests, but this will be hard as I only got experience with Windows/Visual Studio.

Concerning an own wiki page I'll strongly consider setting up a page for this fork and will start working on it as soon as scrypt is finished.

Maybe I'll request some help from you all to code the tests.

BR

JPM

[Mobile Mouse]

Jean-Pierre,

Please check the attached GNUmakefile. I’m afraid the other one I sent wasn’t the final version. :-(

Please let me know if there are any questions, or problems (hopefully none).

[Zooko O'Whielacronx]

On Thu, Jan 1, 2015 at 10:11 AM, Jean-Pierre Münch
<jean.pier...@gmail.com> wrote:
>
> Happy New Year. (2015)

Same to you! Thank you for working on CryptoJPM!

> So there are some questions open I need to ask you:
> - Do you want Skein-MAC?
> - Do you want BLAKE and BLAKE2 or just BLAKE2 ?

I want just BLAKE2, and I want BLAKE2-MAC. :-)

Regards,

Zooko

[Jean-Pierre Münch]

Hey everyone,

@mouse:
If I'm not too stupid to see the file you mentioned, you didn't attach it.

@Zooko:
As I'm a huge fan of Skein/Threefish and I noticed that Skein-MAC isn't that more complicated than Skein I'll add Skein-MAC.
Concerning BLAKE2:
Do you want all four BLAKE2-Versions with their MAC-versions? --> 8 new classes?

If so I'll do my best to deliver before end of January.

BR

JPM

[Jeffrey Walton]

> I'm currently working on something that might interest you:
> The modernization of Crypto++ !
>
> I'm accumulating source code and sometimes writing some of my own in preparation of integration into the library.

A wiki category was created to help track modifications that might be useful for this sort of thing: http://www.cryptopp.com/wiki/Category:Patch

Its on the wiki because that's where I dump most of my changes. I think its helpful to users because the wiki is part of Crypto++ and provides a central location to find things. Using the wiki as a central location means its somewhat official, it can be edited and/or improved by anyone with an interest, and folks don't have to scour the web for potentially incorrect or wrong information.

Jeff

[Jeffrey Walton]

> Post as reply if you think something needs to be added to the list.

I'm really interested in Bernstein's gear (Zooko: did you suggest this yet?). That would include curve25519 and its Diffie-Hellman function (http://cr.yp.to/ecdh.html), Poly1305 for MACs (http://cr.yp.to/mac.html) and ed25519 for signatures (http://ed25519.cr.yp.to/).

What I'm unsure about: Bernstein takes great care to implement constant time operations, and I'm not sure if C++ can capture it. I'm thinking that most libraries (like Crypto++ or Botan) that wants to adhere to Bernstein's specification in both letter and spirit should probably wrap Bernstein's implementation. That is, compile Bernstein's gear, provide the wrapper and link to the relevant object files.

There's also the open questions about identifiers and format for Bernstein's gear. For example, how to identify X509 pubic key or a PKCS8 private key.

On Tuesday, December 23, 2014 9:47:21 AM UTC-5, Jean-Pierre Münch wrote:

[Mobile Mouse]

And I’d be happy enough with the existing implementations. Because working with Dan’s code wasn’t all that great in my experience.

[Jeffrey Walton]

On Sat, Jan 3, 2015 at 10:53 PM, Mobile Mouse <mous...@gmail.com> wrote:
> And I’d be happy enough with the existing implementations. Because working
> with Dan’s code wasn’t all that great in my experience.

+1. Anyone who has complained about OpenSSL or Crypto++ has probably
not had the pleasure of NaCl. (Is there any documentation yet?)

Jeff

[Mobile Mouse]

:-) I’m not aware of any docs worth talking about.

So back to my point: let’s keep Crypto++ as is (plus additional algorithms of course), without taking anything from NaCl.

Those who fancy NaCl can take it and have all the pleasure they want (and I daresay deserve :).

[Zooko O'Whielacronx]

Here's my argument for why you should use BLAKE2: because BLAKE (the
original) was the real winner of the SHA-3 competition. ;-)

slides version:

https://blake2.net/acns/slides.html

blog post version:

https://leastauthority.com/blog/BLAKE2-harder-better-faster-stronger-than-MD5.html

> Concerning BLAKE2:
> Do you want all four BLAKE2-Versions with their MAC-versions? --> 8 new
> classes?

Yes, please! I'm sorry there are so many versions. ☹

Regards,

Zooko

[Jeffrey Walton]

On Sat, Jan 3, 2015 at 11:26 PM, Mobile Mouse <mous...@gmail.com> wrote:
> On Jan 3, 2015, at 23:16 , Jeffrey Walton <nolo...@gmail.com> wrote:
>> On Sat, Jan 3, 2015 at 10:53 PM, Mobile Mouse <mous...@gmail.com> wrote:
>>> And I’d be happy enough with the existing implementations. Because working
>>> with Dan’s code wasn’t all that great in my experience.
>> +1. Anyone who has complained about OpenSSL or Crypto++ has probably
>> not had the pleasure of NaCl. (Is there any documentation yet?)
>
> :-) I’m not aware of any docs worth talking about.
>
> So back to my point: let’s keep Crypto++ as is (plus additional algorithms of course), without taking anything from NaCl.
>

Yeah, good point.

[Jean-Pierre Münch]

Hey everyone,

my wiki page's up: http://www.cryptopp.com/wiki/CryptoJPM

@zooko: BLAKE2 will be (fully) included, but Skein will be more versatile (see SKEINROX).

@mouse: Sorry but I don't see the attached makefile :-(. Please retry posting it here and if it fails, we'll find a way.

Concerning the discussion on the Bernstein functions:
I'd be willing include the curves, but I won't make any changes to the logic that processes ECs. So there'd be no advantage as this curve requires modifications of the generic logic implemented in Crypto++.
Everyone who already had to do with EC-Crypto knows what I mean.

BR

JPM

[Mobile Mouse]

On Jan 4, 2015, at 5:38 , Jean-Pierre Münch <jean.pier...@gmail.com> wrote:
> @mouse: Sorry but I don't see the attached makefile :-(. Please retry posting it here and if it fails, we'll find a way.

Your mailer must be weird. ;)

Below I’ll just paste it.

> Concerning the discussion on the Bernstein functions:
> I'd be willing include the curves,

Yes!

> but I won't make any changes to the logic that processes ECs. So there'd be no advantage as this curve requires modifications of the generic logic implemented in Crypto++.
> Everyone who already had to do with EC-Crypto knows what I mean.

YES!!!

#!/usr/bin/env make

SO = so
LIBLDFLAGS =
LDLIBS =
#-lstdc++
CXX=g++
#CXX=g++-mp-4.8
#CXX=clang++-mp-3.4
#CXX=clang++

# -O3 fails to link on Cygwin GCC version 4.5.3
CXXFLAGS = -DNDEBUG -O3 -Ofast -Wno-unused-value

# These are required on newer Mac OS X, as somehow they aren't set
# up automatically even when the native CPU supports them.
CXXFLAGS += -maes -mpclmul -mavx2


# -fPIC is supported. Please report any breakage of -fPIC as a bug.
CXXFLAGS += -fPIC
# the following options reduce code size, but breaks link or makes
# link very slow on some systems
CXXFLAGS += -ffunction-sections -fdata-sections
# The following seems to break link on Mac OS X
# LDFLAGS += -Wl,--gc-sections
ARFLAGS = -cr # ar needs the dash on OpenBSD
RANLIB = ranlib
CP = cp -f
MKDIR = mkdir -p
EGREP = egrep
UNAME = $(shell uname)
ISX86 = $(shell uname -m | $(EGREP) -c "i.86|x86|i86|amd64")
IS_SUN_CC = $(shell $(CXX) -V 2>&1 | $(EGREP) -c "CC: Sun")
IS_LINUX = $(shell $(CXX) -dumpmachine 2>&1 | $(EGREP) -c "linux")
IS_MINGW = $(shell $(CXX) -dumpmachine 2>&1 | $(EGREP) -c "mingw")
CLANG_COMPILER = $(shell $(CXX) --version 2>&1 | $(EGREP) -i -c "clang version")

# Default prefix for make install
ifeq ($(PREFIX),)
PREFIX = /usr
endif

ifeq ($(CXX),gcc) # for some reason CXX is gcc on cygwin 1.1.4
CXX = g++
endif


ifeq ($(ISX86),1)

GCC42_OR_LATER = $(shell $(CXX) -v 2>&1 | $(EGREP) -c "^gcc version (4.[2-9]|[5-9])")
INTEL_COMPILER = $(shell $(CXX) --version 2>&1 | $(EGREP) -c "\(ICC\)")
ICC111_OR_LATER = $(shell $(CXX) --version 2>&1 | $(EGREP) -c "\(ICC\) ([2-9][0-9]|1[2-9]|11\.[1-9])")
GAS210_OR_LATER = $(shell $(CXX) -xc -c /dev/null -Wa,-v -o/dev/null 2>&1 | $(EGREP) -c "GNU assembler version (2\.[1-9][0-9]|[3-9])")
GAS217_OR_LATER = $(shell $(CXX) -xc -c /dev/null -Wa,-v -o/dev/null 2>&1 | $(EGREP) -c "GNU assembler version (2\.1[7-9]|2\.[2-9]|[3-9])")
GAS219_OR_LATER = $(shell $(CXX) -xc -c /dev/null -Wa,-v -o/dev/null 2>&1 | $(EGREP) -c "GNU assembler version (2\.19|2\.[2-9]|[3-9])")


ifneq ($(INTEL_COMPILER),0)
CXXFLAGS += -wd68 -wd186 -wd279 -wd327
ifeq ($(ICC111_OR_LATER),0)
# "internal error: backend signals" occurs on some x86 inline assembly with ICC 9 and some x64 inline assembly with ICC 11.0
# if you want to use Crypto++'s assembly code with ICC, try enabling it on individual files
CXXFLAGS += -DCRYPTOPP_DISABLE_ASM
endif
endif

ifeq ($(GAS210_OR_LATER),0) # .intel_syntax wasn't supported until GNU assembler 2.10
CXXFLAGS += -DCRYPTOPP_DISABLE_ASM
else
ifeq ($(GAS217_OR_LATER),0)
CXXFLAGS += -DCRYPTOPP_DISABLE_SSSE3
else
ifeq ($(GAS219_OR_LATER),0)
CXXFLAGS += -DCRYPTOPP_DISABLE_AESNI
endif
endif
ifeq ($(UNAME),SunOS)
CXXFLAGS += -Wa,--divide # allow use of "/" operator
endif
endif

endif # ISX86

ifeq ($(UNAME),) # for DJGPP, where uname doesn't exist
CXXFLAGS += -mbnu210
else
#CXXFLAGS += -pipe
endif

ifeq ($(IS_MINGW),1)
LDLIBS += -lws2_32
endif

ifeq ($(IS_LINUX),1)
LDFLAGS += -pthread
ifneq ($(shell uname -i | $(EGREP) -c "(_64|d64)"),0)
M32OR64 = -m64
endif
endif

ifeq ($(UNAME),Darwin)
AR = libtool
ARFLAGS = -static -o
CXXFLAGS += -m64 -arch x86_64 # -arch i386
LIBLDFLAGS += -dynamiclib
SO = dylib
ifeq ($(CXX),g++)
# On Mac OS X this employs native assembler that knows AES-NI
CXXFLAGS += -Wa,-q
else
# These are for Xcode clang++ for compatibility with gcc stuff
CXXFLAGS += -stdlib=libstdc++
LDLIBS += -lstdc++
LIBLDFLAGS += -stdlib=libstdc++
endif
else
SO = so
endif

ifeq ($(UNAME),SunOS)
LDLIBS += -lnsl -lsocket
M32OR64 = -m$(shell isainfo -b)
endif

ifneq ($(CLANG_COMPILER),0)
CXXFLAGS += -Wno-tautological-compare
endif

ifneq ($(IS_SUN_CC),0) # override flags for CC Sun C++ compiler
CXXFLAGS = -DNDEBUG -O -g0 -native -template=no%extdef $(M32OR64)
LDFLAGS =
AR = $(CXX)
ARFLAGS = -xar -o
RANLIB = true
SUN_CC10_BUGGY = $(shell $(CXX) -V 2>&1 | $(EGREP) -c "CC: Sun .* 5\.10 .* (2009|2010/0[1-4])")
ifneq ($(SUN_CC10_BUGGY),0)
# -DCRYPTOPP_INCLUDE_VECTOR_CC is needed for Sun Studio 12u1 Sun C++ 5.10 SunOS_i386 128229-02 2009/09/21 and was fixed in May 2010
# remove it if you get "already had a body defined" errors in vector.cc
CXXFLAGS += -DCRYPTOPP_INCLUDE_VECTOR_CC
endif
endif

SRCS = $(wildcard *.cpp)
ifeq ($(SRCS),) # workaround wildcard function bug in GNU Make 3.77
SRCS = $(shell echo *.cpp)
endif

OBJS = $(SRCS:.cpp=.o)
# test.o needs to be after bench.o for cygwin 1.1.4 (possible ld bug?)
TESTOBJS = bench.o bench2.o test.o validat1.o validat2.o validat3.o adhoc.o datatest.o regtest.o fipsalgt.o dlltest.o
LIBOBJS = $(filter-out $(TESTOBJS),$(OBJS))

DLLSRCS = algebra.cpp algparam.cpp asn.cpp basecode.cpp cbcmac.cpp channels.cpp cryptlib.cpp des.cpp dessp.cpp dh.cpp dll.cpp dsa.cpp ec2n.cpp eccrypto.cpp ecp.cpp eprecomp.cpp files.cpp filters.cpp fips140.cpp fipstest.cpp gf2n.cpp gfpcrypt.cpp hex.cpp hmac.cpp integer.cpp iterhash.cpp misc.cpp modes.cpp modexppc.cpp mqueue.cpp nbtheory.cpp oaep.cpp osrng.cpp pch.cpp pkcspad.cpp pubkey.cpp queue.cpp randpool.cpp rdtables.cpp rijndael.cpp rng.cpp rsa.cpp sha.cpp simple.cpp skipjack.cpp strciphr.cpp trdlocal.cpp
DLLOBJS = $(DLLSRCS:.cpp=.export.o)
LIBIMPORTOBJS = $(LIBOBJS:.o=.import.o)
TESTIMPORTOBJS = $(TESTOBJS:.o=.import.o)
DLLTESTOBJS = dlltest.dllonly.o

all: cryptest.exe
static: libcryptopp.a
dynamic: libcryptopp.$(SO)
shared: dynamic

test: cryptest.exe
./cryptest.exe v

clean:
-$(RM) cryptest.exe libcryptopp.a libcryptopp.$(SO) $(LIBOBJS) $(TESTOBJS) cryptopp.dll libcryptopp.dll.a libcryptopp.import.a cryptest.import.exe dlltest.exe $(DLLOBJS) $(LIBIMPORTOBJS) $(TESTI MPORTOBJS) $(DLLTESTOBJS)

install: libcryptopp.a
$(MKDIR) -p $(PREFIX)/include/cryptopp $(PREFIX)/lib $(PREFIX)/bin
-$(CP) *.h $(PREFIX)/include/cryptopp
-$(CP) *.a $(PREFIX)/lib
-$(RANLIB) $(PREFIX)/lib/libcryptopp.a
-$(CP) *.exe $(PREFIX)/bin
-$(CP) *.$(SO) $(PREFIX)/lib

remove:
-$(RM) -rf $(PREFIX)/include/cryptopp
-$(RM) $(PREFIX)/lib/libcryptopp.a
-$(RM) $(PREFIX)/lib/libcryptopp.$(SO)
-$(RM) $(PREFIX)/bin/cryptest.exe

libcryptopp.a: $(LIBOBJS)
$(AR) $(ARFLAGS) $@ $(LIBOBJS)
$(RANLIB) $@

libcryptopp.$(SO): $(LIBOBJS)
$(CXX) $(LIBLDFLAGS) -o $@ $(LIBOBJS) $(LDLIBS)
# $(CXX) -shared $(LIBLDFLAGS) -o $@ $(LIBOBJS) $(LDLIBS)

cryptest.exe: libcryptopp.a $(TESTOBJS)
$(CXX) -o $@ $(CXXFLAGS) $(TESTOBJS) ./libcryptopp.a $(LDFLAGS) $(LDLIBS)

nolib: $(OBJS) # makes it faster to test changes
$(CXX) -o ct $(CXXFLAGS) $(OBJS) $(LDFLAGS) $(LDLIBS)

dll: cryptest.import.exe dlltest.exe

cryptopp.dll: $(DLLOBJS)
$(CXX) -shared -o $@ $(CXXFLAGS) $(DLLOBJS) $(LDFLAGS) $(LDLIBS) -Wl,--out-implib=libcryptopp.dll.a

libcryptopp.import.a: $(LIBIMPORTOBJS)
$(AR) $(ARFLAGS) $@ $(LIBIMPORTOBJS)
$(RANLIB) $@

cryptest.import.exe: cryptopp.dll libcryptopp.import.a $(TESTIMPORTOBJS)
$(CXX) -o $@ $(CXXFLAGS) $(TESTIMPORTOBJS) -L. -lcryptopp.dll -lcryptopp.import $(LDFLAGS) $(LDLIBS)

dlltest.exe: cryptopp.dll $(DLLTESTOBJS)
$(CXX) -o $@ $(CXXFLAGS) $(DLLTESTOBJS) -L. -lcryptopp.dll $(LDFLAGS) $(LDLIBS)

adhoc.cpp: adhoc.cpp.proto
ifeq ($(wildcard adhoc.cpp),)
cp adhoc.cpp.proto adhoc.cpp
else
touch adhoc.cpp
endif

%.dllonly.o : %.cpp
$(CXX) $(CXXFLAGS) -DCRYPTOPP_DLL_ONLY -c $< -o $@

%.import.o : %.cpp
$(CXX) $(CXXFLAGS) -DCRYPTOPP_IMPORTS -c $< -o $@

%.export.o : %.cpp
$(CXX) $(CXXFLAGS) -DCRYPTOPP_EXPORTS -c $< -o $@

%.o : %.cpp
$(CXX) $(CXXFLAGS) -c $<

[Jean-Pierre Münch]

Hey everyone,

I've got good and bad news.

Good news is, SKEINROX is available now. (featuring support for Skein-MAC, Skein-KDF and Skein-Digital-Signature-Hashing and Personalization).
New Version (5.7.0 beta 1.2) is appended.

Bad news:
Scrypt isn't working. I don't know why. It should work, as I hit specification and do pretty much the same as Percival's implementation does, but I won't get the correct test vector results.
Could you guys please look into the code? (header is in scrypt.h, main functions (SMIX, BLOCKMIX, SALSA, INTEGERIFY) are in scrypt.cpp, test vectors are in the symmetric test vector file (with check code for VS2012))

Next thing to be done (I'll get myself a few days distance to my scrypt implementation) is wrapping of BLAKE2 family.

BR

JPM

[Andreas Tscharner]

On 01.01.2015 11:11, Jean-Pierre Münch wrote:
> Hey everyone,

Hello,
>
> Happy New Year. (2015)

Happy new year to you too!

>
> First of all:
> I've got some things finished.
> The current state of the library is zipped and appended.

Do you use Github or another platform?

Best regards
Andreas
--
Andreas Tscharner sterne...@gmail.com
------------------------------------------------------------------------
Der entscheidende Vorteil eines Chats gegenueber einem normalen Telefon-
anruf ist der, dass ersterer langsamer geht und mehr kostet (fuer den
lebenswichtigen Austausch von Informationen wie "hya folks", "C U
l8er" und ":-)") ... Aus Murphy's Computergesetzen

[Jean-Pierre Münch]

As of now I don't use any online source code platform.
The way I do organize my source code at the moment is like a normal small project with VisualStudio in a folder on my external HDD.

BR

JPM

[Jeffrey Walton]

Hi Mouse,

I'd suggest a couple of small corrections here...

*****

Change:

    CXX=g++

to:

     CXX ?= g++

That keeps the makefile from stepping on the compiler set in the environment. If its not set, then the  assignment is performed. Its particularly painful when cross-compiling.

Ditto for RANLIB.

*****

Change:

    CLANG_COMPILER = $(shell $(CXX) --version 2>&1 | $(EGREP) -i -c "clang version")

To:

    CLANG_COMPILER = $(shell $(CXX) --version 2>&1 | $(EGREP) -i -c "clang")

Apple uses "clang version", while building it from sources does not. So if you built your own Clang or used one from a distro, then its usually mis-identified.

You should make the above change and then try Mac OS X again and see if you have the same problems with the assembler.

*****

-Os is usually more useful than -O2 or -O3 because it keeps the code tighter and caches hotter.

*****

libcryptopp.so target is missing both CXXFLAGS and LDFLAGS.

*****

By the way, here's a diff of the Makefile I use (it has a few more changes): http://pastebin.com/xCYekFQ0

Jeff

[Jeffrey Walton]

On Sunday, January 4, 2015 11:27:12 AM UTC-5, Jean-Pierre Münch wrote:

 

Bad news:
Scrypt isn't working. I don't know why. It should work, as I hit specification and do pretty much the same as Percival's implementation does, but I won't get the correct test vector results.
Could you guys please look into the code? (header is in scrypt.h, main functions (SMIX, BLOCKMIX, SALSA, INTEGERIFY) are in scrypt.cpp, test vectors are in the symmetric test vector file (with check code for VS2012))

Emailing a TARBALL or ZIP file doesn't seem like a good solution. You should probably put this on something like Github for easy access and version control.

I'm not a big Git fan, but this seems like an ideal project for Git because its distributed in nature.

[Mobile Mouse]

On Jan 4, 2015, at 21:14 , Jeffrey Walton <nolo...@gmail.com> wrote:

Hi Mouse,

I'd suggest a couple of small corrections here…

Thank you!

Change:
    CXX=g++ 
to:
     CXX ?= g++ 

That keeps the makefile from stepping on the compiler set in the environment. If its not set, then the  assignment is performed. Its particularly painful when cross-compiling.

Great point! I’ll do that, and hope Jean-Pierre will do the same.

Ditto for RANLIB.

Same.

Change:
    CLANG_COMPILER = $(shell $(CXX) --version 2>&1 | $(EGREP) -i -c "clang version") 
To:
    CLANG_COMPILER = $(shell $(CXX) --version 2>&1 | $(EGREP) -i -c "clang”) 

Hmm, OK. Won’t impact me, as I don’t use non-Apple clang any more, but makes sense for the Crypto++ distro. 

Apple uses "clang version", while building it from sources does not. So if you built your own Clang or used one from a distro, then its usually mis-identified.

Yeah… 

You should make the above change and then try Mac OS X again and see if you have the same problems with the assembler.

What do you mean? That I wouldn’t need to manually add those “-maes -mpclmul” flags? I don’t think so. I’ve experimented on other (not CryptoPP) files, and haven’t found a way to have those flags on unless explicitly set.

Am I missing anything here?

Oh, and with the above (and below :) changes it still works fine on Mac OS X 10.9.5 (Xcode 6.1).

-Os is usually more useful than -O2 or -O3 because it keeps the code tighter and caches hotter.

Changed in my makefile, hope Jean-Pierre will do the same. Haven’t noticed size changes, haven’t run the benchmarks (yet).

libcryptopp.so target is missing both CXXFLAGS and LDFLAGS.

It does not need CXXFLAGS (I think) because it’s linking only. Thanks for catching missing LDFLAGS! I’ve added them.

By the way, here's a diff of the Makefile I use (it has a few more changes):http://pastebin.com/xCYekFQ0

Thanks, but no thanks. :-)

I abhor “-arch x86_64 -arch i386”

Here’s the updated makefile:

#!/usr/bin/env make

SO = so

LIBLDFLAGS =

LDLIBS = 

CXX ?= g++

#CXX ?=clang++

# These are Mouse-specific

#CXX=g++-mp-4.8

#CXX=clang++-mp-3.4

# -O3 fails to link on Cygwin GCC version 4.5.3

CXXFLAGS  = -DNDEBUG -Os -Ofast -Wno-unused-value

# These are required on newer Mac OS X, as somehow they aren't set

# up automatically even when the native CPU supports them.

CXXFLAGS += -maes -mpclmul -mavx2

# -fPIC is supported. Please report any breakage of -fPIC as a bug.

CXXFLAGS += -fPIC

# the following options reduce code size, but breaks link or makes 

# link very slow on some systems

CXXFLAGS += -ffunction-sections -fdata-sections

# The following seems to break link on Mac OS X

# LDFLAGS += -Wl,--gc-sections

ARFLAGS = -cr # ar needs the dash on OpenBSD

RANLIB ?= ranlib

CP = cp -f

MKDIR = mkdir -p

EGREP = egrep

UNAME = $(shell uname)

ISX86 = $(shell uname -m | $(EGREP) -c "i.86|x86|i86|amd64")

IS_SUN_CC = $(shell $(CXX) -V 2>&1 | $(EGREP) -c "CC: Sun")

IS_LINUX = $(shell $(CXX) -dumpmachine 2>&1 | $(EGREP) -c "linux")

IS_MINGW = $(shell $(CXX) -dumpmachine 2>&1 | $(EGREP) -c "mingw")

CLANG_COMPILER = $(shell $(CXX) --version 2>&1 | $(EGREP) -i -c "clang")

$(CXX) $(LIBLDFLAGS) -o $@ $(LIBOBJS) $(LDFLAGS) $(LDLIBS)

[Jeffrey Walton]

> Hmm, OK. Won’t impact me, as I don’t use non-Apple clang any more, but makes
> sense for the Crypto++ distro.

Check it out... I'm on OS X 10.8.5, fully patched. No more "clang
version" string - only "clang" string:

$ g++ -v
Configured with:
--prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix

$ g++ --version
Configured with:
--prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix

Sadly, I'm the guy who gave the string to Wei :( Its was around 2011
or 2012, back when Apple provided Clang, and the version string was
something like "Apple clang version ...". Now its "Apple LLVM ..."
with a Clang version number. And if you build from scratch (or use a
distro), its only "clang" string.

> # These are required on newer Mac OS X, as somehow they aren't set
> # up automatically even when the native CPU supports them.
> CXXFLAGS += -maes -mpclmul -mavx2

I'm still using older stuff. I refused the OS X 10.9 upgrade because
of moving the KeyChain to the iCloud. I don't do clouds.

Do you know of any OS X machines that are [internet] accessible to test on?

> It does not need CXXFLAGS (I think) because it’s linking only. Thanks for
> catching missing LDFLAGS! I’ve added them.

The compiler driver (CXX) is invoking the linker (LD). The compiler
driver will pick up some flags and automatically perform some linker
magic (like implicitly adding libraries). To convince yourself, change
CXXFLAGS to:

CXXFLAGS += -stdlib=libc++
CXXFLAGS += -fsanitize=undefined

And let me know how linking goes ;) You can test it with a `make dynamic`.

> I abhor “-arch x86_64 -arch i386”

I've kinda grown to like it. The fat binaries make it easy to a
library to a project. Maybe I'm getting too lazy in my old age.

Jeff

> ...

[Jean-Pierre Münch]

Hey everyone,

code's now online on GitHub.
@Jeff:
Is the .diff file you posted on pastebin, still the most actual one?
If not, you can also (pull request?) on GitHub now.

BR

JPM

[Mobile Mouse]

On Jan 5, 2015, at 0:09 , Jeffrey Walton <nolo...@gmail.com> wrote:

Hmm, OK. Won’t impact me, as I don’t use non-Apple clang any more, but makes
sense for the Crypto++ distro.

Check it out... I'm on OS X 10.8.5, fully patched. No more "clang
version" string - only "clang" string:

Oh, I did - my logic was “this patch doesn’t make things worse for me, but helps somebody else”.

As I said, it works.

Sadly, I'm the guy who gave the string to Wei :( Its was around 2011
or 2012, back when Apple provided Clang, and the version string was
something like "Apple clang version ...". Now its "Apple LLVM ..."
with a Clang version number. And if you build from scratch (or use a
distro), its only "clang" string.

It’s OK, you’ve atoned for your sin. :-)

Now it’s Apple’s time. :-)

# These are required on newer Mac OS X, as somehow they aren't set
# up automatically even when the native CPU supports them.
CXXFLAGS += -maes -mpclmul -mavx2

I'm still using older stuff. I refused the OS X 10.9 upgrade because
of moving the KeyChain to the iCloud. I don't do clouds.

You mean - the older CPU that doesn’t have AES-NI, etc.?

Do you know of any OS X machines that are [internet] accessible to test on?

:-(   Sorry, I don’t. 

It does not need CXXFLAGS (I think) because it’s linking only. Thanks for
catching missing LDFLAGS! I’ve added them.

The compiler driver (CXX) is invoking the linker (LD). The compiler
driver will pick up some flags and automatically perform some linker
magic (like implicitly adding libraries). To convince yourself, change
CXXFLAGS to:

   CXXFLAGS += -stdlib=libc++

Yes, but since I already have “-stdlib=…” in LDLIBFLAGS (setting matching what’s in CXXFLAGS!) that is passed to the linker, is it worth bothering?

   CXXFLAGS += -fsanitize=undefined

Hmm… Do we need this?

And let me know how linking goes ;) You can test it with a `make dynamic`.

:-)

I abhor “-arch x86_64 -arch i386”

I've kinda grown to like it. The fat binaries make it easy to a
library to a project. Maybe I'm getting too lazy in my old age.

I don’t have spare disk space, and I don’t have a non-64-bit machines any more. So no point to complicate life with fat binaries for me.

BTW, cryptopp-5.6.2 builds nicely with Apple native clang (Xode-6.1), and with gcc-4.8.3. However with gcc-4.9.1 the compiled executable (statically-linked!) crashes:

Testing MessageDigest algorithm SHA-512.

...

Tests complete. Total tests = 15. Failed tests = 0.

Testing MessageDigest algorithm SHA-3-224.

......Process 12434 stopped

* thread #1: tid = 0x8ca9e5, 0x000000010018f9ce cryptest.exe`CryptoPP::xorbuf(unsigned char*, unsigned char const*, unsigned long) + 222, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)

    frame #0: 0x000000010018f9ce cryptest.exe`CryptoPP::xorbuf(unsigned char*, unsigned char const*, unsigned long) + 222

cryptest.exe`CryptoPP::xorbuf(unsigned char*, unsigned char const*, unsigned long) + 222:

-> 0x10018f9ce:  vmovdqa %ymm0, (%r13,%r10)

   0x10018f9d5:  addq   $0x20, %r10

   0x10018f9d9:  cmpq   %r9, %rbx

   0x10018f9dc:  jb     0x10018f9bd               ; CryptoPP::xorbuf(unsigned char*, unsigned char const*, unsigned long) + 205

(lldb) bt

* thread #1: tid = 0x8ca9e5, 0x000000010018f9ce cryptest.exe`CryptoPP::xorbuf(unsigned char*, unsigned char const*, unsigned long) + 222, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)

  * frame #0: 0x000000010018f9ce cryptest.exe`CryptoPP::xorbuf(unsigned char*, unsigned char const*, unsigned long) + 222

    frame #1: 0x00000001001d71ab cryptest.exe`CryptoPP::SHA3::Update(unsigned char const*, unsigned long) + 75

(lldb) 

[Jeffrey Walton]

> CXXFLAGS += -fsanitize=undefined
>
> Hmm… Do we need this?

On occasion.

When Whirlpool was failing its self tests under Intel's compiler (ICPC
and ICC), I used Clang and its undefined behavior sanitizer to locate
the offending code. That's where this mess came from (from misc.h):

template <class T> inline T rotrMod(T x, unsigned int y)
{
y %= sizeof(T)*8;
return T((x>>y) | (x<<(sizeof(T)*8-y)));
}

The modular reduction side stepped the undefined behavior by keeping
the shift amount less than or equal to a register size.

I also use -fsanitize=undefined and -fsanitize=address on my patches
to ensure they are not introducing undefined behavior or memory
errors. (In addition to -Wall -Wextra).

Clang's Asan (Address Sanitizer) is a good tool. It performs dynamic
analysis, all its positives are real hits, and does not emulate some
instructions like Valgrind.

Jeff

[Mobile Mouse]

On Jan 5, 2015, at 14:48 , Jeffrey Walton <nolo...@gmail.com> wrote:
>> CXXFLAGS += -fsanitize=undefined
>>
>> Hmm… Do we need this?
>
> On occasion.
>
> When Whirlpool was failing its self tests under Intel's compiler (ICPC
> and ICC), I used Clang and its undefined behavior sanitizer to locate
> the offending code.

Well, even the latest release of Apple clang does not support this flag. And since I’ve had unpleasant experience of having compiled code running correctly when built by Xcode clang, but crashing with SEGV when built by clang installed via Macports - I chose to stay away from Macports clang (and from Macports gcc-4.9, which cannot produce a working CryptoPP).

Or do I need an extra tool to employ -fsanitize=undefined?

[Jeffrey Walton]

> Or do I need an extra tool to employ -fsanitize=undefined?

No, its built into Clang.

The Undefined Behavior Sanitizer (UBSan) is based on John Reghr's
Integer Overflow Checker (but it has a lot more checks now).
http://embed.cs.utah.edu/ioc/.

> I chose to stay away from Macports clang

I don't know about Macports since I don't really use it.

Attached is my recipe to build Clang from sources. It looks like it
needs to be updated for Clang 3.5.0.

I've never had a problem with it (well, except on OS X).

Jeff

[Mobile Mouse]

On Jan 5, 2015, at 21:04 , Jeffrey Walton <nolo...@gmail.com> wrote:

Or do I need an extra tool to employ -fsanitize=undefined?

No, its built into Clang.

:-(

Attached is my recipe to build Clang from sources. It looks like it
needs to be updated for Clang 3.5.0.

Ah, this flag is Clang-3.5 and later, correct?

I've never had a problem with it (well, except on OS X).

And I don’t have a use for it except on OS X :-)

It is my main development platform, especially since Ubuntu 14.02 LTS became irreversibly dead after that silly Nvidia security patch that killed by Linux VM. :-(

On Mon, Jan 5, 2015 at 8:41 PM, Mobile Mouse <mous...@gmail.com> wrote:

On Jan 5, 2015, at 14:48 , Jeffrey Walton <nolo...@gmail.com> wrote:

 CXXFLAGS += -fsanitize=undefined

Hmm… Do we need this?

On occasion.

When Whirlpool was failing its self tests under Intel's compiler (ICPC
and ICC), I used Clang and its undefined behavior sanitizer to locate
the offending code.

Well,  even the latest release of Apple clang does not support this flag. And since I’ve had unpleasant experience of having compiled code running correctly when built by Xcode clang, but crashing with SEGV when built by clang installed via Macports - I chose to stay away from Macports clang (and from Macports gcc-4.9, which cannot produce a working CryptoPP).

Or do I need an extra tool to employ -fsanitize=undefined?

That's where this mess came from (from misc.h):

  template <class T> inline T rotrMod(T x, unsigned int y)
  {
      y %= sizeof(T)*8;
      return T((x>>y) | (x<<(sizeof(T)*8-y)));
  }

The modular reduction side stepped the undefined behavior by keeping
the shift amount less than or equal to a register size.

I also use -fsanitize=undefined and -fsanitize=address on my patches
to ensure they are not introducing undefined behavior or memory
errors. (In addition to -Wall -Wextra).

Clang's Asan (Address Sanitizer) is a good tool. It performs dynamic
analysis, all its positives are real hits, and does not emulate some
instructions like Valgrind.

<Missing-Makefile><clang-3.4.2-recipe.sh>

[Jeffrey Walton]

> Ah, this flag is Clang-3.5 and later, correct?

I believe its been available since about Clang 3.3.

> And I don’t have a use for it except on OS X :-)

If you don't build LLDB, then it will work out of the box on OS X and
Linux (just comment out the LLDB stuff). If you omit LLDB, you will
still build LLVM, Clang and Compiler RT. And you can use the Apple
LLDB debugger, if desired.

In fact, the instructions for the Python folks at
https://docs.python.org/devguide/clang.html omitted LLDB because it
was not worth the trouble. The sanitizers are the important tool, not
the debugger.

If you want LLDB, then you need the extra patches for OS X. The
project omitted for LLDB on OS X for some reason. There's still some
stuff you need to do (like get the code signing right so you can
actually debug another process with LLDB). The instructions were in
one of the READMEs somewhere.

> It is my main development platform, especially since Ubuntu 14.02 LTS became
> irreversibly dead after that silly Nvidia security patch that killed by
> Linux VM. :-(

Haha. Fedora, Ubuntu and Windows died (to me) when they tried to put
those Tablet Managers (GNOME3, Unity and Windows 8) on my desktop.
(Fedora 20 even managed to break GNOME-classic). I use Linux Mint and
Windows 7 now because the Desktop Manager is really a desktop manager,
and not a tablet manager.

They should drug test every executive and manager who thought that
shit was a good idea. They shouldn't be running companies or
departments.

******

The sanitizers are worth their weight in gold. They find nearly every
instance of the "why was this code generated incorrectly" without a
thought. (Its usually because of undefined behavior, and a compiler
was ruthless about removing the UB).

Nearly all code under my purview must compile on multiple platforms
(Windows, Linux, OS X, BSD) using multiple compilers (MSCV, GCC, ICPC,
Clang). And the code is subjected to Clang sanitizers. The multiple
platforms and compilers means I can get more FREE static and dynamic
analysis on the code base.

But that's part of my engineering process, and I understand its not
everyone's cup of tea. I don't have a dog in those fights, so I don't
really worry about it. All I can do is suggest it.

Jeff

[Jean-Pierre Münch]

Hey everyone,

single threaded versions of BLAKE2 (conforming with Crypto++/JPM interfaces) are now on github.
Multithreaded versions will follow soon.

@zooko:
Can you please post valid test vectors either here or on the BLAKE2 website? (two or three per version)

@mouse & jeffrey:
I did not update the makefile yet according to your discussion.

@everyone:
If you know since which version your compiler supports std::thread class, please post the version number. Thank You.

BR

JPM

[Zooko O'Whielacronx]

On Wed, Jan 7, 2015 at 2:48 PM, Jean-Pierre Münch <jean.pier...@gmail.com> wrote:

@zooko:
Can you please post valid test vectors either here or on the BLAKE2 website? (two or three per version)

 

I forwarded your letter to Jean-Philippe Aumasson, and he posted test vectors:

https://blake2.net/#ts

Regards,

Zooko

[Jean-Pierre Münch]

Hey everyone,

I've tested BLAKE2b code and it passes the test vectors.
However, there is an issue with BLAKE2s.
If i'm using reference code for compression function it'll pass the vectors, but if I use the SSE2 and SSSE3 optimized code it will fail.
I copied the code directly from the reference library blake2_code_20140114.zip and manually selected SSE2 and SSSE3 optimizations.

@zooko:
Could you please check if SSE2 and SSSE3 work correct in BLAKE2s by testing yourself? (-> DON'T HAVE XOP, DON'T HAVE SSE41, DON'T HAVE AVX, HAVE SSE2, HAVE SSSE3)

BR

JPM

[Jean-Pierre Münch]

Hey everyone,

I have some normal work to do so future releases will come less often as before.

But I've found some free hours and finally fully included BLAKE2 family.
But the issue that BLAKE2s' SSE version produces incorrect results is still live.

PEM-Pack is now also online although it was kind of broken.

@Jeffrey:
It might interest what I've changed:
1. I did include "pch.h" as very first header in all CPP-files as this is a requirement in VS
2. I did remove the call to std::transform you make once and replaced it by an equal loop as the call to transform was causing compile-time errors for VS with SDL enabled.

Next thing I'll do is to include the Bouncy-Castle-Patch for ECIES.
Afterwards I'll finally fix scrypt.

At this point (If the BLAKE2 guys confirm the bug and fix it) I'll finally contact Wei Dai as I think I've got enough new stuff to trigger a new release.

Code's live on GitHub as usual.

BR

JPM

[Jean-Pierre Münch]

Hey everyone,

a little update from me concerning the work.
As I was running some tests with X86 code I first noticed that _mm_set_epi64x() isn't supported by MSVC for X86, so I tried to fix this with a macro redirection to _mm_set_epi32() BUT it didn't pass test vector checks.
So I do think that _mm_set_epi32() is the root of all evil as it's used by BLAKE2s, by scrypt and by X86-BLAKE2b. I'll run some tests with an executeble soon (as opposed to unit testing).
As reaction to the ongoing difficulties with SSE code I disabled it locally for BLAKE2s, scrypt and X86-BLAKE2b and enforced the use of reference C code.
As soon as I get positive results, I'll switch back to SSE.

Now some good news:
Fortuna (the CSPRNG) is finished!
It doesn't gather entropy by itself yet (-> there's no AutoSeeded version yet) but at least it *should* run.
Entropy collector is scheduled after the fix for SSE-errors.

Code's not yet on GitHub.

BR

JPM

[Ilya Bizyaev]

Hello!

Great idea! Hope my small experience would help you to improve this lib!

1) There are to asserts in secblock.h:

------------------------------------------------------------------

void deallocate(void *p, size_type n)

{

if (p == GetAlignedArray())

{

assert(n <= S); //!!!

assert(m_allocated); //!!!

m_allocated = false;

SecureWipeArray((pointer)p, n);

}

else

m_fallbackAllocator.deallocate(p, n);

}

---------------------------------------------------------------------

I was hitting one of them in this line:

CFB_Mode<AES>::Decryption gcmDecryption(key, key.size(), iv);

This line worked fine on Ubuntu, but caused troubles on Linux.

The solution I've found on this forum looks like this:

CFB_Mode<AES>::Decryption * cfbDecryption = new CFB_Mode<AES>::Decryption(key, key.size(), iv);

This line works right. Maybe you could find the problem in secblock.h and fix it?

2) Check out this topic: click. That's another problem which occures only on Windows 8.

[Zooko Wilcox-OHearn]

---------- Forwarded message ----------
From: Samuel Neves <sne...@dei.uc.pt>
Date: Thu, Feb 26, 2015 at 3:02 PM
Subject: Re: [BLAKE2] Fwd: Modernization of Crypto++
To: Zooko O'Whielacronx <zoo...@gmail.com>, blake2 <bla...@googlegroups.com>


This looks like a potential codegen bug in MSVC; {GCC, Clang} produce
correct code, from what I can tell. What is the
MSVC version being used here?

On 02/26/2015 01:38 PM, Zooko O'Whielacronx wrote:

> --
> --
> 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.
>

--
You received this message because you are subscribed to the Google
Groups "BLAKE2" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to blake2+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com — “Freedom matters.”
http://theoatmeal.com/comics/email_monster

[Jean-Pierre Münch]

Hey zooko,

I do use Visual Studio 2012 Update 4 on a Windows 7 SP1 machine without any further updates.
I don't know exactly what version this is. (11.x.x.x I guess)

BR

JPM

[Jean-Pierre Münch]

Hey everyone,

works not flowing as hoped. Got a lot of other things to do :-(
BUT nonetheless, a little update:
I added Encrypt-Then-Authenticate as AEAD mode of operation in Crypto++, so you can now construct EtA with any cipher-mode (CFB, OFB, CTR, ..., but NOT ECB), any cipher (AES,...), any MAC (HMAC, VMAC, ...) and any KDF to get IVs and Keys for both.
Hope someone will use this feature and hope I implemented correctly (was confused as not other mode keyed the symmetric cipher... but I did).
There's also been some slight advance in Fortuna, you may see some things, but it's not yet finished and shouldn't be used by now.

Code's on GitHub as usual.

BR

JPM