-
Notifications
You must be signed in to change notification settings - Fork 56
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
Is zeroing of data->internal without reset of data->initialized safe? #204
Comments
AFAIK, the only purpose of the Anyways, I agree upon explicitly setting this to |
Oh, right. I also don't see any uses of it in libxcrypt, not even in much older versions where the struct actually matched glibc's. And now that the struct doesn't even match glibc's, the only compatibility that comes from having this field is that the same source code can be built against either library - but the resulting binaries wouldn't be compatible (portable between libxcrypt and glibc libcrypt) because the struct layout is different. |
This issue is a code review in progress. I see no suitable issue label for that, so am leaving it with none.
While reviewing #201, I looked into other places where we may zeroize the data struct, and found this:
libxcrypt/lib/crypt.c
Line 178 in 88ecfa5
This zeroizes
internal
, but leaves theinitialized
field as-is. For hash implementations that compute and cache constants ininternal
, like I thinkdescrypt
does, doesn't this result in incorrect computation on the next call?How does this even pass tests? Maybe I'm misinformed and our
descrypt
doesn't cache anything anymore?Let's at least figure this out.
The text was updated successfully, but these errors were encountered: