Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. And I trust you... why?

And I trust you... why?

Scheduled Pinned Locked Moved The Lounge
cryptographyc++comperformancequestion
24 Posts 12 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • P peterchen

    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 0x80000000

    Version 5.6.0 released
      - improved AES and SHA-256 speed on x86 and x64

    Well, 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 released

    Wait, 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

    S Offline
    S Offline
    Single Step Debugger
    wrote on last edited by
    #11

    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.

    L 1 Reply Last reply
    0
    • C CPallini

      What is the problem? Do you fear the Ides of March?

      Veni, vidi, vici.

      P Offline
      P Offline
      peterchen
      wrote on last edited by
      #12

      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

      L 1 Reply Last reply
      0
      • S Single Step Debugger

        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.

        L Offline
        L Offline
        Lost User
        wrote on last edited by
        #13

        It's slightly more complicated..

        S 1 Reply Last reply
        0
        • L Lost User

          It's slightly more complicated..

          S Offline
          S Offline
          Single Step Debugger
          wrote on last edited by
          #14

          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.

          1 Reply Last reply
          0
          • P peterchen

            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 0x80000000

            Version 5.6.0 released
              - improved AES and SHA-256 speed on x86 and x64

            Well, 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 released

            Wait, 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

            U Offline
            U Offline
            unitrunker
            wrote on last edited by
            #15

            Why did you wait 14 months to tell them? :)

            1 Reply Last reply
            0
            • P peterchen

              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 0x80000000

              Version 5.6.0 released
                - improved AES and SHA-256 speed on x86 and x64

              Well, 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 released

              Wait, 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

              C Offline
              C Offline
              Chris Losinger
              wrote on last edited by
              #16

              peterchen wrote:

              non-SSE2 x86

              aka Pentium 3 or earlier. http://en.wikipedia.org/wiki/SSE2[^]

              image processing toolkits | batch image processing

              L 1 Reply Last reply
              0
              • P peterchen

                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 0x80000000

                Version 5.6.0 released
                  - improved AES and SHA-256 speed on x86 and x64

                Well, 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 released

                Wait, 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

                L Offline
                L Offline
                Lost User
                wrote on last edited by
                #17

                Now tell them that they're running late by almost 3 months to release version 5.6.2. :)

                1 Reply Last reply
                0
                • C Chris Losinger

                  peterchen wrote:

                  non-SSE2 x86

                  aka Pentium 3 or earlier. http://en.wikipedia.org/wiki/SSE2[^]

                  image processing toolkits | batch image processing

                  L Offline
                  L Offline
                  Lost User
                  wrote on last edited by
                  #18

                  Or an AMD K7, which is slightly more recent than the P3, but not much.

                  1 Reply Last reply
                  0
                  • L Lost User

                    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".

                    P Offline
                    P Offline
                    peterchen
                    wrote on last edited by
                    #19

                    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

                    L 1 Reply Last reply
                    0
                    • E Ennis Ray Lynch Jr

                      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

                      P Offline
                      P Offline
                      peterchen
                      wrote on last edited by
                      #20

                      But eyeballs! :cool:

                      FILETIME to time_t
                      | FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy

                      1 Reply Last reply
                      0
                      • P peterchen

                        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

                        L Offline
                        L Offline
                        Lost User
                        wrote on last edited by
                        #21

                        Sure... if you have an ancient CPU, which you don't. Or if your buffer crosses 0x80000000, which it won't.

                        P 1 Reply Last reply
                        0
                        • P peterchen

                          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

                          L Offline
                          L Offline
                          Lost User
                          wrote on last edited by
                          #22

                          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.

                          C 1 Reply Last reply
                          0
                          • L Lost User

                            Sure... if you have an ancient CPU, which you don't. Or if your buffer crosses 0x80000000, which it won't.

                            P Offline
                            P Offline
                            peterchen
                            wrote on last edited by
                            #23

                            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

                            1 Reply Last reply
                            0
                            • L Lost User

                              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.

                              C Offline
                              C Offline
                              CPallini
                              wrote on last edited by
                              #24

                              Collin Jasnoch wrote:

                              Only for x86

                              :laugh:

                              Veni, vidi, vici.

                              1 Reply Last reply
                              0
                              Reply
                              • Reply as topic
                              Log in to reply
                              • Oldest to Newest
                              • Newest to Oldest
                              • Most Votes


                              • Login

                              • Don't have an account? Register

                              • Login or register to search.
                              • First post
                                Last post
                              0
                              • Categories
                              • Recent
                              • Tags
                              • Popular
                              • World
                              • Users
                              • Groups