1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
|
CONTENTS OF THIS FILE
---------------------
* Introduction
* Building the Library
* Alternate Build Systems
* Installing the Library
* Makefile Targets
* Dynamic Analysis
* Acceptance Testing
* Reporting problems
INTRODUCTION
------------
Crypto++ Library is a free C++ class library of cryptographic algorithms and schemes. It was written and placed in public domain by Wei Dai. The library homepage is at http://www.cryptopp.com/. The latest library source code can be found at http://github.com/weidai11/cryptopp. For licensing and copyright information, please see License.txt.
These are general instructions for the BSDs, Linux, OS X, Solaris and Unix. The library uses a GNU makefile, which combines configuration and a non-anemic make. On BSD and Solaris you will likely have to use `gmake` to build the library. On Linux, OS X and Unix, the system's make should be OK. On Windows, Crypto++ provides Borland and Visual Studio solutions.
You should look through the GNUmakefile and config.h to ensure settings look reasonable before building. You are strogly encouraged to use `config.recommend` in place of `config.h` if you are building the library and you can recompile dependent programs.
Wiki pages are available for some platforms with specific build instructions. The wiki can be found at http://cryptopp.com/wiki/. The pages include Android, ARM, iOS and Solaris. Solaris users should visit the wiki for important information on compiling the library with different versions of SunCC and options, and information on improving library performance and features.
Crypto++ does not depend upon other tools or libraries. It does not use Autotools, does not use CMake, and does not use Boost. If you use an alternate build system, like Autotools or CMake, then see the warning below about CXXFLAGS and lack of -DNDEBUG. CMake is available in Master as a matter of convenience, but its not officially supported.
BUILDING THE LIBRARY
--------------------
In general, all you should have to do is open a terminal, and then:
make
make test
sudo make install
The command above builds the static library and cryptest.exe program. If you want to build the shared object, then issue:
make static dynamic cryptest.exe
Or:
make libcryptopp.a libcryptopp.so cryptest.exe
If you would like to use a different compiler, the set CXX:
export CXX=/opt/intel/bin/icpc
make
If you want to build using C++11, then:
make CXXFLAGS="-std=c++11"
Or:
CXXFLAGS="-std=c++11"
make
LLVM's libc++ is also supported, so you can:
CXXFLAGS="-std=c++11 -stdlib=libc++"
make
ALTERNATE BUILD SYSTEMS
-----------------------
The Crypto++ library is Make based and uses GNU Make by default. The makefile uses '-DNDEBUG -g2 -O2' CXXFLAGS by default. If you use an alternate build system, like Autotools or CMake, then ensure the build system includes '-DNDEBUG' for production or release builds. The Crypto++ library uses asserts for debugging and diagnostics during development; it does not rely on them to crash a program at runtime.
If an assert triggers in production software, then unprotected sensitive information could be egressed from the program to the filesystem or the platform's error reporting program, like Apport on Ubuntu or CrashReporter on Apple.
INSTALLING THE LIBRARY
----------------------
To install the library into a user selected directory, perform:
make install PREFIX=/usr/local
If you are going to run `make install PREFIX=/usr/local`, then you should build with '-DCRYPTOPP_DATA_DIR='\"$PREFIX/share/cryptopp/\"' to ensure cryptest.exe can locate the test data files and test vectors after installation. The trailing slash in the path is needed because simple preprocessor concatenation is used.
During install, the makefile copies cryptest.exe into $PREFIX/bin, copies headers into $PREFIX/include/cryptopp, and copies libraries into $PREFIX/lib. If you only built a static or dynamic version of the library, then only one library is copied. The install recipe does not fail if the static library or shared object is not built.
PREFIX is non-standard, but its retained for historical purposes. The makefile also responds to `prefix=<path>`.
MAKEFILE TARGETS
----------------
The following are some of the targets provided by the GNU makefile.
`make` invokes the default rule, which builds the Crypto++ static library and test harness. They are called `libcryptopp.a` and `cryptest.exe`, respectively. `cryptest.exe` links against `libcryptopp.a`, so the static library is a prerequisite for the target.
`make libcryptopp.a` and `make static` build the static version of the library.
`make libcryptopp.so` and `make dynamic` build the dynamic version of the library. On Mac OS X, the recipe builds `libcryptopp.dylib` instead.
`make cryptest.exe` builds the library test harness.
`make test` and `make check` are the same recipe and invoke the test harness with the the validation option. That is, it executes `cryptest.exe v`.
`make install` installs the library. By default, the makefile copies into `/usr/local` by default.
`make clean` cleans most transient and temporary objects.
`make disclean` cleans most objects that are not part of the original distribution.
`make dist` and `make zip` builds ZIP file that is suitable for distribution.
`make iso` builds an ISO on Linux or OS X that is suitable for alternate distribution.
`make ubsan` and `make asan` builds the library with the respective sanitizer.
DYNAMIC ANALYSIS
----------------
The Crypto++ embraces tools like Undefined Behavior sanitizer (UBsan), Address sanitizer (Asan) and Valgrind. Both Clang 3.2 and above and GCC 4.8 and above provide sanitizers. Please check with your distribution on how to install the compiler with its sanitizer libraries (they are sometimes a separate install item).
UBsan and Asan are mutually exclusive options, so you can perform only one of these at a time:
make ubsan
./cryptest.exe v 2>&1 | egrep "(error|FAILED)"
./cryptest.exe tv all 2>&1 | egrep "(error|FAILED)"
Or:
make asan
./cryptest.exe v 2>&1 | egrep "(error|FAILED)"
./cryptest.exe tv all 2>&1 | egrep "(error|FAILED)"
If you experience self test failures or see reports of undefined behavior, then you should ensure CRYPTOPP_NO_UNALIGNED_DATA_ACCESS is defined in config.h. CRYPTOPP_NO_UNALIGNED_DATA_ACCESS is not defined due to historical purposes.
If you experience failures under Asan, then gather more information with:
./cryptest.exe v 2>&1 | asan_symbolize
If you moved Crypto++ such that the paths have changed, then perform:
./cryptest.exe v 2>&1 | sed "s/<old path>/<new path>/g" | asan_symbolize
ACCEPTANCE TESTING
------------------
Crypto++ uses five security gates in its engineering process. The library must maintain the quality provided by the review system and integrity of the test suites. You can use the information to decide if the Crypto++ library suits your needs and provides a compatible security posture.
The first gate is code review and discussion of proposed patches. Git commits often cross reference a User Group discussions.
Second is the compiler warning system. The code must clean compile under the equivalent of GCC's -Wall -Wextra (modulo -Wno-type-limits -Wno-unknown-pragmas). This is a moving target as compiler analysis improves.
Third, the code must pass cleanly though GCC and Clang's Undefined Behavior sanitizer (UBsan) and Address sanitizer (Asan) with CRYPTOPP_NO_UNALIGNED_DATA_ACCESS defined in config.h. See DYNAMIC ANALYSIS above on how to execute them.
Fourth, the test harness provides a "validation" option which performs basic system checks (like endianess and word sizes) and exercises algorithms (like AES and SHA). You run the validation suite as shown below. The tail of the output should indicate 0 failed tests.
./cryptest.exe v
...
All tests passed!
Test ended at Sun Jul 26 02:10:57 2015
Seed used was: 1437891055
Fifth, the test harness provides a "test vector" option which uses many known test vectors, even those published by other people (like Brian Gladman for AES). You run the test vectors as shown below. The tail of the output should indicate 0 failed tests.
./cryptest.exe tv all
...
Testing SymmetricCipher algorithm MARS/ECB.
.................
Tests complete. Total tests = 4094. Failed tests = 0.
The library also offers its test script for those who want to use it. The test script is names cryptest.sh, and it repeatedly builds the library and exectues the tests under various configurations. It takes 2 to 4 hours to run on a semi-modern desktop or server; and days to run on an IoT gadget. Also see http://github.com/weidai11/cryptopp/blob/master/cryptest.sh and http://cryptopp.com/wiki/Cryptest.sh.
REPORTING PROBLEMS
------------------
Dirty compiles and failures in the validation suite or test vectors should be reported at the Crypto++ User Group. The User Group is located at http://groups.google.com/forum/#!forum/cryptopp-users.
Also see http://www.cryptopp.com/wiki/Bug_Report.
|
