-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected behavior from ConstByteArrayParameter with deepCopy true #1066
Comments
Thanks @SpaceCheetah,
Yeah, something sounds sideways here.
I don't think What version of the library are you using? This sounds like the bug we fixed at Issue 1010. The 1010 issue was against HIGHT, but it applied to any cipher or mode using |
After cloning and building it as a static library, I got completely different results with deepCopy true, but exact same with deepCopy false. deepCopy true: 95 251 243 163 245 17 230 231 202 88 30 90 (edit: it seems to give a different value each time, which definitely isn't right) Still definitely wrong, but at least one of the changes since 8.5.0 affected something. To me this implies that the deepCopy true behavior is the incorrect one, since false seems to be static accross versions and other languages (in particular Java's javax.crypto.Cipher.getInstance("AES/CFB8/NoPadding")) give the same result. |
Ok so apparently with the current master, when deepCopy is true it's running as if it has a different IV each time. That looks like it's using uninitialized memory somewhere, as there certainly isn't a call to random. Did some more testing, if I just iterate over a ConstByteArrayParameter deepCopy doesn't change anything. Also, constructing the AlgorithmmParameters and then getting the value with params.GetValue still doesn't show this behavior. Is it with SetKey then somehow? |
I believe the problem here is,
You usually use |
I don't think it's overriding exactly, since this works:
That outputs 0123456789abcdef, as expected, whether deepCopy is true or false. I considered if it was with a move or copy constructor, but trying both operations with AlgorithmParameters doesn't mess it up. As for working around the issue, it's fairly easy to just not use deepCopy and keep the data around, which is what I ended up doing on my project; however it seems like quite an easy issue to run into, and the solution is very non-obvious. |
Decided to try setting m_register to public (changed modes.h ln 127 from protected to public). Using that, I checked the value with
I expected: 48 49 50 51 52 53 54 55 56 57 97 98 99 100 101 102 |
perhaps the reasons are the same as here #1042 |
I was using a ConstByteArrayParameter with
AlgorithmParameters params = MakeParameters(Name::FeedbackSize(), 1)( Name::IV(), ConstByteArrayParameter( buf, len, /*deepCopy*/ true));
Using that with AES CFB encryption, it was encrypting to a different value with the same key and iv as another library. Eventually, I found that changing deepCopy from true to false fixed it.
I looked more into it and this appears to be because with deepCopy it sets m_mark to ELEMS_MAX, while without deepCopy it doesn't. I don't understand the code enough to understand what that actually effects.
Script showing this behavior:
Output:
deepCopy = true: 54 212 37 247 60 195 31 237 151 174 121 229
deepCopy = false: 38 139 250 34 92 236 75 111 42 125 55 140
Other libraries give, for the same key, the result with deepCopy false.
Even if the deepCopy true behavior is correct and the other libraries are just wrong, a copy flag still shouldn't affect the end behavior, right?
The text was updated successfully, but these errors were encountered: