| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
Also see https://groups.google.com/forum/#!topic/cryptopp-users/A7-Xt5Knlzw
|
| |
|
|
|
|
| |
Users of OldRandomPool must use the new interface. All that means is they must call IncorporateEntropy instead of Put, and GenerateBlock instead of Get
|
|
|
|
|
|
|
|
| |
The existing interface still exists. The new interface is routed into the old methods. Without the new interface, using OldRandPool could result in:
$ ./cryptest.exe v
terminate called after throwing an instance of CryptoPP::NotImplemented
what(): RandomNumberGenerator: IncorporateEntropy not implemented
Aborted (core dumped)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RandomPool used to be a PGP-style deterministic generator and folks used it as a key generation function. At Crypto++ 5.5 the design changed to harden it agianst rollback attacks. The design change resulted in an upgrade barrier. That is, some folks are stuck at Crypto++ 4.2 or Crypto++ 5.2 because they must interoperate with existing software.
Below is the test program we used for the test vector. It was run against Crypto++ 5.4.
RandomPool prng;
SecByteBlock seed(0x00, 384), result(64);
prng.Put(seed, seed.size());
prng.GenerateBlock(result, result.size());
HexEncoder encoder(new FileSink(std::cout));
std::cout << "RandomPool: ";
encoder.Put(result, sizeof(result));
std::cout << std::endl;
|
|
|
|
|
|
| |
This should have happened when we removed most of MAINTAIN_BACKWARDS_COMPATIBILITY artifacts. Its not practical move SHA1 into Weak:: namespace or "typedef SHA256 SHA" because SHA1 is too intertwined at the moment.
In the interim, maybe we can place SHA1 in both CryptoPP:: and Weak:: namespaces. This will allow us to transition into Weak::SHA1 over time, and signal to users SHA1 should be avoided.
|
|
|
|
| |
We have made a fair number of changes, and we don't want WD to receive credit for issues he was not part of
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|