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
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279

/*
The MIT License (MIT)
Copyright (c) 2015 Christophe Meessen
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
*/
/* Minimally modified for libgnunetutil: added license header
(from https://github.com/chmike/cst_time_memcmp, LICENSE file), and
renamed the exported symbol: */
#define consttime_memcmp GNUNET_memcmp_ct_
/* Rest of the file is 'original' */
#include <stddef.h>
#include <inttypes.h>
/*
* "constant time" memcmp. Time taken depends on the buffer length, of
* course, but not on the content of the buffers.
*
* Just like the ordinary memcmp function, the return value is
* tristate: <0, 0, or >0. However, applications that need a
* constanttime memory comparison function usually need only a
* twostate result, signalling only whether the inputs were identical
* or different, but not signalling which of the inputs was larger.
* This code could be made significantly faster and simpler if the
* requirement for a tristate result were removed.
*
* In order to protect against adversaries who can observe timing,
* cache hits or misses, page faults, etc., and who can use such
* observations to learn something about the relationship between the
* contents of the two buffers, we have to perform exactly the same
* instructions and memory accesses regardless of the contents of the
* buffers. We can't stop as soon as we find a difference, we can't
* take different conditional branches depending on the data, and we
* can't use different pointers or array indexes depending on the data.
*
* Further reading:
*
* .Rs
* .%A Paul C. Kocher
* .%T Timing Attacks on Implementations of DiffieHellman, RSA, DSS, and Other Systems
* .%D 1996
* .%J CRYPTO 1996
* .%P 104113
* .%U http://www.cryptography.com/timingattack/paper.html
* .%U http://www.webcitation.org/query?url=http%3A%2F%2Fwww.cryptography.com%2Ftimingattack%2Fpaper.html&date=20121017
* .Re
*
* .Rs
* .%A D. Boneh
* .%A D. Brumley
* .%T Remote timing attacks are practical
* .%D August 2003
* .%J Proceedings of the 12th Usenix Security Symposium, 2003
* .%U https://crypto.stanford.edu/~dabo/abstracts/ssltiming.html
* .%U http://www.webcitation.org/query?url=https%3A%2F%2Fcrypto.stanford.edu%2F%7Edabo%2Fabstracts%2Fssltiming.html&date=20121017
* .%U http://www.webcitation.org/query?url=http%3A%2F%2Fcrypto.stanford.edu%2F%7Edabo%2Fpubs%2Fpapers%2Fssltiming.pdf&date=20121017
* .Es
*
* .Rs
* .%A Coda Hale
* .%T A Lesson In Timing Attacks (or, Don't use MessageDigest.isEquals)
* .%D 13 Aug 2009
* .%U http://codahale.com/alessonintimingattacks/
* .%U http://www.webcitation.org/query?url=http%3A%2F%2Fcodahale.com%2Falessonintimingattacks%2F&date=20121017
* .Re
*
*/
/*
* A note on portability:
*
* We assume that char is exactly 8 bits, the same as uint8_t, and that
* integer types with exactly 16 bits and exactly 32 bits exist. (If
* there is ever a need to change this, then the actual requirement is
* that we need a type that is at least two bits wider than char, and
* another type that is at least two bits wider than that, or we need to
* fake it somehow.)
*
* We do not assume any particular size for the plain "int" type, except
* that it is at least 16 bits, as is guaranteed by the C language
* standard.
*
* We do not assume that signed integer overflow is harmless. We
* ensure that signed integer overflow does not occur, so that
* implementationdefined overflow behaviour is not invoked.
*
* We rely on the C standard's guarantees regarding the wraparound
* behaviour of unsigned integer arithmetic, and on the analagous
* guarantees regarding conversions from signed types to narrower
* unsigned types.
*
* We do not assume that the platform uses two's complement arithmetic.
*/
/*
* How hard do we have to try to prevent unwanted compiler optimisations?
*
* Try compiling with "#define USE_VOLATILE_TEMPORARY 0", and examine
* the compiler output. If the only conditional tests in the entire
* function are to test whether len is zero, then all is well, but try
* again with different optimisation flags to be sure. If the compiler
* emitted code with conditional tests that do anything other than
* testing whether len is zero, then that's a problem, so try again with
* "#define USE_VOLATILE_TEMPORARY 1". If it's still bad, then you are
* out of luck.
*/
#define USE_VOLATILE_TEMPORARY 0
int
consttime_memcmp (const void *b1, const void *b2, size_t len)
{
const uint8_t *c1, *c2;
uint16_t d, r, m;
#if USE_VOLATILE_TEMPORARY
volatile uint16_t v;
#else
uint16_t v;
#endif
c1 = b1;
c2 = b2;
r = 0;
while (len)
{
/*
* Take the low 8 bits of r (in the range 0x00 to 0xff,
* or 0 to 255);
* As explained elsewhere, the low 8 bits of r will be zero
* if and only if all bytes compared so far were identical;
* Zeroextend to a 16bit type (in the range 0x0000 to
* 0x00ff);
* Add 255, yielding a result in the range 255 to 510;
* Save that in a volatile variable to prevent
* the compiler from trying any shortcuts (the
* use of a volatile variable depends on "#ifdef
* USE_VOLATILE_TEMPORARY", and most compilers won't
* need it);
* Divide by 256 yielding a result of 1 if the original
* value of r was nonzero, or 0 if r was zero;
* Subtract 1, yielding 0 if r was nonzero, or 1 if r
* was zero;
* Convert to uint16_t, yielding 0x0000 if r was
* nonzero, or 0xffff if r was zero;
* Save in m.
*/v = ((uint16_t) (uint8_t) r) + 255;
m = v / 256  1;
/*
* Get the values from *c1 and *c2 as uint8_t (each will
* be in the range 0 to 255, or 0x00 to 0xff);
* Convert them to signed int values (still in the
* range 0 to 255);
* Subtract them using signed arithmetic, yielding a
* result in the range 255 to +255;
* Convert to uint16_t, yielding a result in the range
* 0xff01 to 0xffff (for what was previously 255 to
* 1), or 0, or in the range 0x0001 to 0x00ff (for what
* was previously +1 to +255).
*/d = (uint16_t) ((int) *c1  (int) *c2);
/*
* If the low 8 bits of r were previously 0, then m
* is now 0xffff, so (d & m) is the same as d, so we
* effectively copy d to r;
* Otherwise, if r was previously nonzero, then m is
* now 0, so (d & m) is zero, so leave r unchanged.
* Note that the low 8 bits of d will be zero if and
* only if d == 0, which happens when *c1 == *c2.
* The low 8 bits of r are thus zero if and only if the
* entirety of r is zero, which happens if and only if
* all bytes compared so far were equal. As soon as a
* nonzero value is stored in r, it remains unchanged
* for the remainder of the loop.
*/r = (d & m);
/*
* Increment pointers, decrement length, and loop.
*/
++c1;
++c2;
len;
}
/*
* At this point, r is an unsigned value, which will be 0 if the
* final result should be zero, or in the range 0x0001 to 0x00ff
* (1 to 255) if the final result should be positive, or in the
* range 0xff01 to 0xffff (65281 to 65535) if the final result
* should be negative.
*
* We want to convert the unsigned values in the range 0xff01
* to 0xffff to signed values in the range 255 to 1, while
* converting the other unsigned values to equivalent signed
* values (0, or +1 to +255).
*
* On a machine with two's complement arithmetic, simply copying
* the underlying bits (with sign extension if int is wider than
* 16 bits) would do the job, so something like this might work:
*
* return (int16_t)r;
*
* However, that invokes implementationdefined behaviour,
* because values larger than 32767 can't fit in a signed 16bit
* integer without overflow.
*
* To avoid any implementationdefined behaviour, we go through
* these contortions:
*
* a. Calculate ((uint32_t)r + 0x8000). The cast to uint32_t
* it to prevent problems on platforms where int is narrower
* than 32 bits. If int is a larger than 32bits, then the
* usual arithmetic conversions cause this addition to be
* done in unsigned int arithmetic. If int is 32 bits
* or narrower, then this addition is done in uint32_t
* arithmetic. In either case, no overflow or wraparound
* occurs, and the result from this step has a value that
* will be one of 0x00008000 (32768), or in the range
* 0x00008001 to 0x000080ff (32769 to 33023), or in the range
* 0x00017f01 to 0x00017fff (98049 to 98303).
*
* b. Cast the result from (a) to uint16_t. This effectively
* discards the high bits of the result, in a way that is
* well defined by the C language. The result from this step
* will be of type uint16_t, and its value will be one of
* 0x8000 (32768), or in the range 0x8001 to 0x80ff (32769 to
* 33023), or in the range 0x7f01 to 0x7fff (32513 to
* 32767).
*
* c. Cast the result from (b) to int32_t. We use int32_t
* instead of int because we need a type that's strictly
* larger than 16 bits, and the C standard allows
* implementations where int is only 16 bits. The result
* from this step will be of type int32_t, and its value wll
* be one of 0x00008000 (32768), or in the range 0x00008001
* to 0x000080ff (32769 to 33023), or in the range 0x00007f01
* to 0x00007fff (32513 to 32767).
*
* d. Take the result from (c) and subtract 0x8000 (32768) using
* signed int32_t arithmetic. The result from this step will
* be of type int32_t and the value will be one of
* 0x00000000 (0), or in the range 0x00000001 to 0x000000ff
* (+1 to +255), or in the range 0xffffff01 to 0xffffffff
* (255 to 1).
*
* e. Cast the result from (d) to int. This does nothing
* interesting, except to make explicit what would have been
* implicit in the return statement. The final result is an
* int in the range 255 to +255.
*
* Unfortunately, compilers don't seem to be good at figuring
* out that most of this can be optimised away by careful choice
* of register width and sign extension.
*
*/return (/*e*/ int) (/*d*/
(/*c*/ int32_t) (/*b*/ uint16_t) (/*a*/ (uint32_t) r + 0x8000)
 0x8000);
}
