And I trust you... why?
-
I was looking for a reliable SHA256 - C/C++ implementation, and good things were pointing to Crypto++. With the downside that I need only a single function, not a framework to run all kinds of hash functions in, it looked fine. Until I read that excerpt:
Version 5.6.1 released
- fixed several bugs in the SHA-256 x86/x64 assembly code:
incorrect hash on non-SSE2 x86 machines on non-aligned input
incorrect hash on x86 machines when input crosses 0x80000000Version 5.6.0 released
- improved AES and SHA-256 speed on x86 and x64Well, ok, happens to the best of us I guess. But let me ad some boilerplate decoration:
8/9/2010 - Version 5.6.1 released
3/15/2009 - Version 5.6.0 releasedWait, what? 8/9/2010 - Version 5.6.1 released 3/15/2009 - Version 5.6.0 released Are you elephanting kidding me? [edit] Generating potentially incorrect SHA's for over a year? Well, never mind, I'll write it on my own, can't be that hard.[/sarcasm]
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyWhy not use CryptCreateHash[^] with CALG_SHA256 ?
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS My LinkedIn Profile
-
I think the point is that it took them well over a year to fix what seems like a pretty serious bug.
-
I think the point is that it took them well over a year to fix what seems like a pretty serious bug.
Depends when they were made aware it existed. If all their testing was on SSE2 x86 or above machines, it could have been a year before they were even told there was a problem.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
I was looking for a reliable SHA256 - C/C++ implementation, and good things were pointing to Crypto++. With the downside that I need only a single function, not a framework to run all kinds of hash functions in, it looked fine. Until I read that excerpt:
Version 5.6.1 released
- fixed several bugs in the SHA-256 x86/x64 assembly code:
incorrect hash on non-SSE2 x86 machines on non-aligned input
incorrect hash on x86 machines when input crosses 0x80000000Version 5.6.0 released
- improved AES and SHA-256 speed on x86 and x64Well, ok, happens to the best of us I guess. But let me ad some boilerplate decoration:
8/9/2010 - Version 5.6.1 released
3/15/2009 - Version 5.6.0 releasedWait, what? 8/9/2010 - Version 5.6.1 released 3/15/2009 - Version 5.6.0 released Are you elephanting kidding me? [edit] Generating potentially incorrect SHA's for over a year? Well, never mind, I'll write it on my own, can't be that hard.[/sarcasm]
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyIf I recall correctly SHA-hash is a simple set of XOR operations. Better implement it yourself. Xoring buffers in C/C++ is a no brainer.
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
-
Over 16 months of "generating invalid SHA's". Just imagining the dungstorm of a pool of wrong-SHA'd data accumulated over a year.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
If I recall correctly SHA-hash is a simple set of XOR operations. Better implement it yourself. Xoring buffers in C/C++ is a no brainer.
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
-
It could be, what I’ve done was SHA-1, probably SHA256 is more complicated.
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
-
I was looking for a reliable SHA256 - C/C++ implementation, and good things were pointing to Crypto++. With the downside that I need only a single function, not a framework to run all kinds of hash functions in, it looked fine. Until I read that excerpt:
Version 5.6.1 released
- fixed several bugs in the SHA-256 x86/x64 assembly code:
incorrect hash on non-SSE2 x86 machines on non-aligned input
incorrect hash on x86 machines when input crosses 0x80000000Version 5.6.0 released
- improved AES and SHA-256 speed on x86 and x64Well, ok, happens to the best of us I guess. But let me ad some boilerplate decoration:
8/9/2010 - Version 5.6.1 released
3/15/2009 - Version 5.6.0 releasedWait, what? 8/9/2010 - Version 5.6.1 released 3/15/2009 - Version 5.6.0 released Are you elephanting kidding me? [edit] Generating potentially incorrect SHA's for over a year? Well, never mind, I'll write it on my own, can't be that hard.[/sarcasm]
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyWhy did you wait 14 months to tell them? :)
-
I was looking for a reliable SHA256 - C/C++ implementation, and good things were pointing to Crypto++. With the downside that I need only a single function, not a framework to run all kinds of hash functions in, it looked fine. Until I read that excerpt:
Version 5.6.1 released
- fixed several bugs in the SHA-256 x86/x64 assembly code:
incorrect hash on non-SSE2 x86 machines on non-aligned input
incorrect hash on x86 machines when input crosses 0x80000000Version 5.6.0 released
- improved AES and SHA-256 speed on x86 and x64Well, ok, happens to the best of us I guess. But let me ad some boilerplate decoration:
8/9/2010 - Version 5.6.1 released
3/15/2009 - Version 5.6.0 releasedWait, what? 8/9/2010 - Version 5.6.1 released 3/15/2009 - Version 5.6.0 released Are you elephanting kidding me? [edit] Generating potentially incorrect SHA's for over a year? Well, never mind, I'll write it on my own, can't be that hard.[/sarcasm]
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchypeterchen wrote:
non-SSE2 x86
aka Pentium 3 or earlier. http://en.wikipedia.org/wiki/SSE2[^]
-
I was looking for a reliable SHA256 - C/C++ implementation, and good things were pointing to Crypto++. With the downside that I need only a single function, not a framework to run all kinds of hash functions in, it looked fine. Until I read that excerpt:
Version 5.6.1 released
- fixed several bugs in the SHA-256 x86/x64 assembly code:
incorrect hash on non-SSE2 x86 machines on non-aligned input
incorrect hash on x86 machines when input crosses 0x80000000Version 5.6.0 released
- improved AES and SHA-256 speed on x86 and x64Well, ok, happens to the best of us I guess. But let me ad some boilerplate decoration:
8/9/2010 - Version 5.6.1 released
3/15/2009 - Version 5.6.0 releasedWait, what? 8/9/2010 - Version 5.6.1 released 3/15/2009 - Version 5.6.0 released Are you elephanting kidding me? [edit] Generating potentially incorrect SHA's for over a year? Well, never mind, I'll write it on my own, can't be that hard.[/sarcasm]
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
peterchen wrote:
non-SSE2 x86
aka Pentium 3 or earlier. http://en.wikipedia.org/wiki/SSE2[^]
-
Pretty serious bug? The first one may be a little serious, secretly corrupting the result like that.. but it's not very hard to notice and easy to work around. Seriously though, both of those bugs fall into the category of "will never happen anyway".
Serious because acuumulating wrong SHA's over months or even a year is a ventilator-hitting-rear-exhaust-product waiting to happen. In addition, the "wrong" SHA's may be collision-prone or not even stable.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
How much does this "oft-updated" library cost? : )
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
But eyeballs! :cool:
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
Serious because acuumulating wrong SHA's over months or even a year is a ventilator-hitting-rear-exhaust-product waiting to happen. In addition, the "wrong" SHA's may be collision-prone or not even stable.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
Over 16 months of "generating invalid SHA's". Just imagining the dungstorm of a pool of wrong-SHA'd data accumulated over a year.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
Sure... if you have an ancient CPU, which you don't. Or if your buffer crosses 0x80000000, which it won't.
harold aptroot wrote:
if you have an ancient CPU,
If I know beforehand, I can block customers running on this. Otherwise, I don't have much control over that. My clients are "very conservative", to say the least.
harold aptroot wrote:
Or if your buffer crosses 0x80000000, which it won't.
If I know beforehand that I can't use /LARGEADDRESSAWARE, I can do that. Now, yes, the large address space bug is feckin' hard to detect (requires an experienced coder who knows the problem). However, the x86-non-SSE-codepath is pretty darn easy to test even on a system with SSE.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
Only for x86... Maybe they weren't much of a concern.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
