2000-03-08 19:13:32 +03:00
|
|
|
/*
|
Expose CRC32 to testcrypt, and add tests for it.
Finding even semi-official test vectors for this CRC implementation
was hard, because it turns out not to _quite_ match any of the well
known ones catalogued on the web. Its _polynomial_ is well known, but
the combination of details that go alongside it (starting state,
post-hashing transformation) are not quite the same as any other hash
I know of.
After trawling catalogue websites for a while I finally worked out
that SSH-1's CRC and RFC 1662's CRC are basically the same except for
different choices of starting value and final adjustment. And RFC
1662's CRC is common enough that there _are_ test vectors.
So I've renamed the previous crc32_compute function to crc32_ssh1,
reflecting that it seems to be its own thing unlike any other CRC;
implemented the RFC 1662 CRC as well, as an alternative tiny wrapper
on the inner crc32_update function; and exposed all three functions to
testcrypt. That lets me run standard test vectors _and_ directed tests
of the internal update routine, plus one check that crc32_ssh1 itself
does what I expect.
While I'm here, I've also modernised the code to use uint32_t in place
of unsigned long, and ptrlen instead of separate pointer,length
arguments. And I've removed the general primer on CRC theory from the
header comment, in favour of the more specifically useful information
about _which_ CRC this is and how it matches up to anything else out
there.
(I've bowed to inevitability and put the directed CRC tests in the
'crypt' class in cryptsuite.py. Of course this is a misnomer, since
CRC isn't cryptography, but it falls into the same category in terms
of the role it plays in SSH-1, and I didn't feel like making a new
pointedly-named 'notreallycrypt' container class just for this :-)
2019-01-14 23:45:19 +03:00
|
|
|
* CRC32 implementation, as used in SSH-1.
|
|
|
|
*
|
|
|
|
* This particular form of the CRC uses the polynomial
|
|
|
|
* P(x) = x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+1
|
|
|
|
* and represents polynomials in bit-reversed form, so that the x^0
|
|
|
|
* coefficient (constant term) appears in the bit with place value
|
|
|
|
* 2^31, and the x^31 coefficient in the bit with place value 2^0. In
|
|
|
|
* this representation, (x^32 mod P) = 0xEDB88320, so multiplying the
|
|
|
|
* current state by x is done by shifting right by one bit, and XORing
|
|
|
|
* that constant into the result if the bit shifted out was 1.
|
|
|
|
*
|
|
|
|
* There's a bewildering array of subtly different variants of CRC out
|
|
|
|
* there, using different polynomials, both bit orders, and varying
|
|
|
|
* the start and end conditions. There are catalogue websites such as
|
|
|
|
* http://reveng.sourceforge.net/crc-catalogue/ , which generally seem
|
|
|
|
* to have the convention of indexing CRCs by their 'check value',
|
|
|
|
* defined as whatever you get if you hash the 9-byte test string
|
|
|
|
* "123456789".
|
|
|
|
*
|
|
|
|
* The crc32_rfc1662() function below, which starts off the CRC state
|
|
|
|
* at 0xFFFFFFFF and complements it after feeding all the data, gives
|
|
|
|
* the check value 0xCBF43926, and matches the hash function that the
|
|
|
|
* above catalogue refers to as "CRC-32/ISO-HDLC"; among other things,
|
|
|
|
* it's also the "FCS-32" checksum described in RFC 1662 section C.3
|
|
|
|
* (hence the name I've given it here).
|
|
|
|
*
|
|
|
|
* The crc32_ssh1() function implements the variant form used by
|
|
|
|
* SSH-1, which uses the same update function, but starts the state at
|
|
|
|
* zero and doesn't complement it at the end of the computation. The
|
|
|
|
* check value for that version is 0x2DFD2D88, which that CRC
|
|
|
|
* catalogue doesn't list at all.
|
2000-03-08 19:13:32 +03:00
|
|
|
*/
|
1999-01-08 16:02:13 +03:00
|
|
|
|
Expose CRC32 to testcrypt, and add tests for it.
Finding even semi-official test vectors for this CRC implementation
was hard, because it turns out not to _quite_ match any of the well
known ones catalogued on the web. Its _polynomial_ is well known, but
the combination of details that go alongside it (starting state,
post-hashing transformation) are not quite the same as any other hash
I know of.
After trawling catalogue websites for a while I finally worked out
that SSH-1's CRC and RFC 1662's CRC are basically the same except for
different choices of starting value and final adjustment. And RFC
1662's CRC is common enough that there _are_ test vectors.
So I've renamed the previous crc32_compute function to crc32_ssh1,
reflecting that it seems to be its own thing unlike any other CRC;
implemented the RFC 1662 CRC as well, as an alternative tiny wrapper
on the inner crc32_update function; and exposed all three functions to
testcrypt. That lets me run standard test vectors _and_ directed tests
of the internal update routine, plus one check that crc32_ssh1 itself
does what I expect.
While I'm here, I've also modernised the code to use uint32_t in place
of unsigned long, and ptrlen instead of separate pointer,length
arguments. And I've removed the general primer on CRC theory from the
header comment, in favour of the more specifically useful information
about _which_ CRC this is and how it matches up to anything else out
there.
(I've bowed to inevitability and put the directed CRC tests in the
'crypt' class in cryptsuite.py. Of course this is a misnomer, since
CRC isn't cryptography, but it falls into the same category in terms
of the role it plays in SSH-1, and I didn't feel like making a new
pointedly-named 'notreallycrypt' container class just for this :-)
2019-01-14 23:45:19 +03:00
|
|
|
#include <stdint.h>
|
2000-03-08 19:13:32 +03:00
|
|
|
#include <stdlib.h>
|
1999-01-08 16:02:13 +03:00
|
|
|
|
2003-01-06 02:48:10 +03:00
|
|
|
#include "ssh.h"
|
2003-01-06 02:09:53 +03:00
|
|
|
|
2019-01-14 23:46:12 +03:00
|
|
|
/*
|
|
|
|
* Multiply a CRC value by x^4. This implementation strategy avoids
|
|
|
|
* using a lookup table (which would be a side-channel hazard, since
|
|
|
|
* SSH-1 applies this CRC to decrypted session data).
|
2000-03-08 19:13:32 +03:00
|
|
|
*
|
2019-01-14 23:46:12 +03:00
|
|
|
* The basic idea is that you'd like to "multiply" the shifted-out 4
|
|
|
|
* bits by the CRC polynomial value 0xEDB88320, or rather by that
|
|
|
|
* value shifted right 3 bits (since you want the _last_ bit shifted
|
|
|
|
* out, i.e. the one originally at the 2^3 position, to generate
|
|
|
|
* 0xEDB88320 itself). But the scare-quoted "multiply" would have to
|
|
|
|
* be a multiplication of polynomials over GF(2), which differs from
|
|
|
|
* integer multiplication in that you don't have any carries. In other
|
|
|
|
* words, you make a copy of one input shifted left by the index of
|
|
|
|
* each set bit in the other, so that adding them all together would
|
|
|
|
* give you the ordinary integer product, and then you XOR them
|
|
|
|
* together instead.
|
2000-03-08 19:13:32 +03:00
|
|
|
*
|
2019-01-14 23:46:12 +03:00
|
|
|
* With a 4-bit multiplier, the two kinds of multiplication coincide
|
|
|
|
* provided the multiplicand has no two set bits at positions
|
|
|
|
* differing by less than 4, because then no two copies of the
|
|
|
|
* multiplier can overlap to generate a carry. So I break up the
|
|
|
|
* intended multiplicand K = 0xEDB88320 >> 3 into three sub-constants
|
|
|
|
* a,b,c with that property, such that a^b^c = K. Then I can multiply
|
|
|
|
* m by each of them separately, and XOR together the results.
|
2000-03-08 19:13:32 +03:00
|
|
|
*/
|
2019-01-14 23:46:12 +03:00
|
|
|
static inline uint32_t crc32_shift_4(uint32_t v)
|
2001-05-06 18:35:20 +04:00
|
|
|
{
|
2019-01-14 23:46:12 +03:00
|
|
|
const uint32_t a = 0x11111044, b = 0x08840020, c = 0x04220000;
|
|
|
|
uint32_t m = v & 0xF;
|
|
|
|
return (v >> 4) ^ (a*m) ^ (b*m) ^ (c*m);
|
2000-03-08 19:13:32 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2019-01-14 23:46:12 +03:00
|
|
|
* The 8-bit shift you need every time you absorb an input byte,
|
|
|
|
* implemented simply by iterating the 4-bit shift twice.
|
2000-03-08 19:13:32 +03:00
|
|
|
*/
|
2019-01-14 23:46:12 +03:00
|
|
|
static inline uint32_t crc32_shift_8(uint32_t v)
|
2001-05-06 18:35:20 +04:00
|
|
|
{
|
2019-01-14 23:46:12 +03:00
|
|
|
return crc32_shift_4(crc32_shift_4(v));
|
2000-03-08 19:13:32 +03:00
|
|
|
}
|
|
|
|
|
2019-01-14 23:46:12 +03:00
|
|
|
/*
|
|
|
|
* Update an existing hash value with extra bytes of data.
|
|
|
|
*/
|
|
|
|
uint32_t crc32_update(uint32_t crc, ptrlen data)
|
2001-05-06 18:35:20 +04:00
|
|
|
{
|
Expose CRC32 to testcrypt, and add tests for it.
Finding even semi-official test vectors for this CRC implementation
was hard, because it turns out not to _quite_ match any of the well
known ones catalogued on the web. Its _polynomial_ is well known, but
the combination of details that go alongside it (starting state,
post-hashing transformation) are not quite the same as any other hash
I know of.
After trawling catalogue websites for a while I finally worked out
that SSH-1's CRC and RFC 1662's CRC are basically the same except for
different choices of starting value and final adjustment. And RFC
1662's CRC is common enough that there _are_ test vectors.
So I've renamed the previous crc32_compute function to crc32_ssh1,
reflecting that it seems to be its own thing unlike any other CRC;
implemented the RFC 1662 CRC as well, as an alternative tiny wrapper
on the inner crc32_update function; and exposed all three functions to
testcrypt. That lets me run standard test vectors _and_ directed tests
of the internal update routine, plus one check that crc32_ssh1 itself
does what I expect.
While I'm here, I've also modernised the code to use uint32_t in place
of unsigned long, and ptrlen instead of separate pointer,length
arguments. And I've removed the general primer on CRC theory from the
header comment, in favour of the more specifically useful information
about _which_ CRC this is and how it matches up to anything else out
there.
(I've bowed to inevitability and put the directed CRC tests in the
'crypt' class in cryptsuite.py. Of course this is a misnomer, since
CRC isn't cryptography, but it falls into the same category in terms
of the role it plays in SSH-1, and I didn't feel like making a new
pointedly-named 'notreallycrypt' container class just for this :-)
2019-01-14 23:45:19 +03:00
|
|
|
const uint8_t *p = (const uint8_t *)data.ptr;
|
2019-01-14 23:46:12 +03:00
|
|
|
for (size_t len = data.len; len-- > 0 ;)
|
|
|
|
crc = crc32_shift_8(crc ^ *p++);
|
|
|
|
return crc;
|
1999-01-08 16:02:13 +03:00
|
|
|
}
|
2002-01-08 14:57:32 +03:00
|
|
|
|
Expose CRC32 to testcrypt, and add tests for it.
Finding even semi-official test vectors for this CRC implementation
was hard, because it turns out not to _quite_ match any of the well
known ones catalogued on the web. Its _polynomial_ is well known, but
the combination of details that go alongside it (starting state,
post-hashing transformation) are not quite the same as any other hash
I know of.
After trawling catalogue websites for a while I finally worked out
that SSH-1's CRC and RFC 1662's CRC are basically the same except for
different choices of starting value and final adjustment. And RFC
1662's CRC is common enough that there _are_ test vectors.
So I've renamed the previous crc32_compute function to crc32_ssh1,
reflecting that it seems to be its own thing unlike any other CRC;
implemented the RFC 1662 CRC as well, as an alternative tiny wrapper
on the inner crc32_update function; and exposed all three functions to
testcrypt. That lets me run standard test vectors _and_ directed tests
of the internal update routine, plus one check that crc32_ssh1 itself
does what I expect.
While I'm here, I've also modernised the code to use uint32_t in place
of unsigned long, and ptrlen instead of separate pointer,length
arguments. And I've removed the general primer on CRC theory from the
header comment, in favour of the more specifically useful information
about _which_ CRC this is and how it matches up to anything else out
there.
(I've bowed to inevitability and put the directed CRC tests in the
'crypt' class in cryptsuite.py. Of course this is a misnomer, since
CRC isn't cryptography, but it falls into the same category in terms
of the role it plays in SSH-1, and I didn't feel like making a new
pointedly-named 'notreallycrypt' container class just for this :-)
2019-01-14 23:45:19 +03:00
|
|
|
/*
|
|
|
|
* The SSH-1 variant of CRC-32.
|
|
|
|
*/
|
|
|
|
uint32_t crc32_ssh1(ptrlen data)
|
|
|
|
{
|
|
|
|
return crc32_update(0, data);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The official version of CRC-32. Nothing in PuTTY proper uses this,
|
|
|
|
* but it's useful to expose it to testcrypt so that we can implement
|
|
|
|
* standard test vectors.
|
|
|
|
*/
|
|
|
|
uint32_t crc32_rfc1662(ptrlen data)
|
2002-01-08 14:57:32 +03:00
|
|
|
{
|
Expose CRC32 to testcrypt, and add tests for it.
Finding even semi-official test vectors for this CRC implementation
was hard, because it turns out not to _quite_ match any of the well
known ones catalogued on the web. Its _polynomial_ is well known, but
the combination of details that go alongside it (starting state,
post-hashing transformation) are not quite the same as any other hash
I know of.
After trawling catalogue websites for a while I finally worked out
that SSH-1's CRC and RFC 1662's CRC are basically the same except for
different choices of starting value and final adjustment. And RFC
1662's CRC is common enough that there _are_ test vectors.
So I've renamed the previous crc32_compute function to crc32_ssh1,
reflecting that it seems to be its own thing unlike any other CRC;
implemented the RFC 1662 CRC as well, as an alternative tiny wrapper
on the inner crc32_update function; and exposed all three functions to
testcrypt. That lets me run standard test vectors _and_ directed tests
of the internal update routine, plus one check that crc32_ssh1 itself
does what I expect.
While I'm here, I've also modernised the code to use uint32_t in place
of unsigned long, and ptrlen instead of separate pointer,length
arguments. And I've removed the general primer on CRC theory from the
header comment, in favour of the more specifically useful information
about _which_ CRC this is and how it matches up to anything else out
there.
(I've bowed to inevitability and put the directed CRC tests in the
'crypt' class in cryptsuite.py. Of course this is a misnomer, since
CRC isn't cryptography, but it falls into the same category in terms
of the role it plays in SSH-1, and I didn't feel like making a new
pointedly-named 'notreallycrypt' container class just for this :-)
2019-01-14 23:45:19 +03:00
|
|
|
return crc32_update(0xFFFFFFFF, data) ^ 0xFFFFFFFF;
|
2002-01-08 14:57:32 +03:00
|
|
|
}
|