Hi,
We are updating a project which uses the ancient cryptopp 4.2, to the
latest version in order to have better cross platform support (4.2 suffers
from undefined behaviour under platforms like Android/iOS).
In this project, we use AES to decrypt/encrypt some data, nothing to fancy.
Now, the p
Apparently the random pool is the cause of our problems. In 5.6.4 it uses
time and AES instead of no time and MDC in cryptopp 4.2.
Is there anyway to replicate the old randpool behaviour, or are there other
possible solutions?
Op woensdag 21 september 2016 11:06:52 UTC+2 schreef edwin schriek:
>
The issue you seem to have is that the RNG is, well, actually producing
random results.
If you want deterministic behavior, you should avoid RNGs if possible.
To clarify, I'm trying to draw a picture of the old IV generation:
Key -> SHA256 -> RandomPool -> SHA256 -> XOR "compression" -> IV
|
Thanks for your answer,
Your statement about security makes sense, the thing is that this code was
written 20 years ago by some developer and I do not know his
intention/philosophy behind this encryption/decryption mechanism.
With that being said, fixing the current construction, which is consid
After HMAC is keyed (which you did in the constructor and can also do
via SetKey() ) it behaves like a normal hash function, so Update() and
Final() or CalculateDigest() are your methods of choice.
So it would be something like:
HMAC hmac(key,keySize); // replace with your parameters
hmac.Calcula
The change I proposed tried to maintain the same flow as closely as
possible, making HMAC the obvious choice here. If you wanted to exact
same results as from 4.2, you'll either have to inspect the 4.2 code and
try and reproduce the same results (shouldn't be too hard) or you just
copy and paste th
I came up with the following based on your remarks, instantiated the HMAC
with the key and fed the hashest key as the message.
However, output does not coincide with that of the old code.
CryptoPP::SHA256 hash;
m_bufSeed.Resize(hash.DigestSize());
m_bufIV.Resize(IV_SIZE); //16
hash.Calcul
I decided to go with the quick and dirty solution of copying the old
randpool implementation, which works.
Anyhow, thanks for your insight, we will probably make stuff more secure
based on your remarks in the near future.
Op woensdag 21 september 2016 16:51:48 UTC+2 schreef jean-pierre.muench:
> Under cryptopp 4.2, bufSeedIV is always the same, resulting in a bufHash
> and m_bufIV which are always the same.
> Under cryptopp 5.6.4 however, bufSeedIV is always different, this is our
> problem.
>
> As far as I can figure, the RandomPool implementation changed over time,
> but I could
On Wednesday, September 21, 2016 at 11:30:54 AM UTC-4, Jeffrey Walton wrote:
>
>
> Under cryptopp 4.2, bufSeedIV is always the same, resulting in a bufHash
>> and m_bufIV which are always the same.
>> Under cryptopp 5.6.4 however, bufSeedIV is always different, this is our
>> problem.
>>
>> As
Hi Everyone,
I added a couple of switches to cryptest.nmake for convenience when testing
/march:AVX and /march:AVX2. AVX is available in VS2013, and AVX2 is
available in VS2015. Also see
https://github.com/weidai11/cryptopp/commit/e1f0252b71466c62427d661415b27693813bb358.
The library appears w
Thanks, Jeff!
Op woensdag 21 september 2016 17:59:29 UTC+2 schreef Jeffrey Walton:
>
>
>
> On Wednesday, September 21, 2016 at 11:30:54 AM UTC-4, Jeffrey Walton
> wrote:
>>
>>
>> Under cryptopp 4.2, bufSeedIV is always the same, resulting in a bufHash
>>> and m_bufIV which are always the same.
On Monday, September 19, 2016 at 3:34:14 PM UTC-4, Jeffrey Walton wrote:
>
> Hi Everyone,
>
> We added some more tests to verify builds compatible with distros like
> Debian are producing. Under -mach=x86-64, a "minimum" amd64 build, Clang
> broke [badly?]. We added the following to work around
Hi Everyone,
This was a good week. We got a number of patches from the community and
four different submitters introduced breaks. I needed to refine at least
three patches. I think its a good time to share my philosophy, and open it
up for debate.
First, Master needs to be mostly stable. Users
> Sixth, learning from mistakes and is not license to lower expectations. Each
> time I broke the code, I looked beyond the instance problem and questioned
> why it happened in the first place. I then placed controls to stop future
> breaks. Of all the controls that can be placed, we achieve the hi
Hi Everyone,
I have a few additional test scripts I'd like to drop into the source code.
I'm concerned all the scripts, like cryptest.sh, cryptest-ios.sh,
cryptest-android.sh and cryptest-win.pl, are going to move beyond
"reasonable" and into "pollution".
I'd like to crate a TestScript directo
You're doing a great job, Jeffrey. I'm happy to see Crypto++ being
maintained so diligently, and with such precise attention to detail. Thank
you!
On Sep 22, 2016 3:47 AM, "Jeffrey Walton" wrote:
> Hi Everyone,
>
> This was a good week. We got a number of patches from the community and
> four di
Hi Everyone,
New Coverity Scan results are available at
https://scan.coverity.com/projects/cryptopp.
Earlier in the week I ran a few scans against x86_64 to test the Integer
changes (re: Issue 274). We picked up five findings. Three appeared to be
false positives, and two were valid, give or t
18 matches
Mail list logo
