Announcement

Collapse
No announcement yet.

CRC-64 code?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • CRC-64 code?

    Does anyone have PB code to calculate CRC-64? I have used CRC-32 cde from the forums, but am experiencing collisions.

    Thanks in advance,
    Bill Fletcher

    ------------------

  • #2
    I doubt that you will get an affirmative, Bill. CRC 64 never took off. You are not talking cryptographic security else you wouldn't be using CRC 32. I guess your 'move up' may be best accommodated with MD5 at 128 bit. It has been compromised but if used as a checksum it may do if you are 'checking' a lot, of whatever, but if only occasional then I'd push the boat out with 256 or 512.

    Comment


    • #3
      The only code I found (years ago now, when I thought I'd need such a capability for a project at the time):
      http://lists.boost.org/Archives/boost/2002/03/26953.php

      I never ported it to PB, but doing so should be easy enough to make experimenting worth the trouble.


      ------------------

      Comment


      • #4
        Thanks to both of you for your feedback, I'll follow up on Greg's code lead.

        I am not interested in this for cryptography but for hashing purposes, to detect (near) duplicates among webpages I have downloaded for a linguistic corpus. CRC-32 has too many collisions. MD5 works fine for smaller datasets, but it has twice the storage and comparison overhead of CRC-64.

        The data at http://apollo.backplane.com/matt/crc64.html suggests that CRC-64 is robust enough for my purposes.
        (1 collision in 3 trillion items.)


        Regards,
        Bill


        ------------------


        [This message has been edited by Bill Fletcher (edited April 26, 2007).]

        Comment


        • #5
          Originally posted by Bill Fletcher:
          MD5 works fine for smaller datasets, but it has twice the storage and comparison overhead of CRC-64.
          Bill,
          If MD5 is fast enough for your purpose, you could simply strip off any number of bytes you don't need of the MD5 hash value and only keep/use the number of bytes that seems enough for you to avoid many collisions.
          For example, use only the first 8 bytes of the MD5 hash value ... Then you have your 64-bit 'CRC'...

          Kind regards
          ------------------
          Eddy
          www.devotechs.com -- HIME Huge Integer Math and Encryption library--

          [This message has been edited by Eddy Van Esch (edited April 26, 2007).]
          Eddy

          Comment


          • #6
            #if 0
            This is the code I use for CRC-64 type hashing. Obviously, it is
            not modified for you to directly drop in and compile. But consider
            it released to the Public Domain for anybody to modify and use as
            they see fit.

            I have no clue on how to check for the degree of "collisions" that
            this code generates. Greg, Eddy, any hints?

            Obviously, this code has been hacked together over a long period of
            time, and I haven't cleaned it up (yet).

            I intentionally left out the "crchashseed()" code. This code is used
            to a minor extent in some of my security-related stuff, and I don't want to
            publically expose how the seed is derived.
            #endif

            Code:
            function CRCHashquad (byval in1 as string, opt byval vt1 as variant) as quad
                #register none
                local s1 as string
                s1 = string$(8, 0)
                function = 0
                if in1 = "" then exit function
                local seed2 as dword, L as long, L2 as long, L3 as long, L4 as long, L5 as long, L1&
                local count as long
                local qptr as dword
                local count2 as long
                local count3 as long
                local count4 as long
                L2 = (len(s1) \ 4)
                seed2 = crchashseed(vt1, 8)
                static s3$
                if len(s3) = 0 then s3 = chr$(0 to 255)
                if len(in1) < L2 * 5 then
                    L3 = ((len(in1) \ (L2 * 5)) + 1) * (L2 * 5)
                    in1 = in1 + left$(s3, L3 - len(in1))
                end if
                L4 = len(in1) \ L2
                L5 = modint(len(in1), L2)
                local sptr as dword
                sptr = strptr(in1)
                for L1 = L2 to 1 step -1
                    ! pushad
                    ! pushfd
                    ! mov ecx, seed2
                    ! xor ecx, &hffffffff
                    ! mov edi, sptr
                    ! MOV ESI, L4
                    ! cmp L1, 1
                    ! jne noadd
                    ! add esi, L5
                    noadd:
                    ! XOR EAX, EAX
                    NextByte:
                    ! MOV AL, cl
                    ! XOR AL, [EDI]
                    ! shr ecx, 8
                    ! xor ecx, dword ptr crc32table[eax*4]
                    ! INC EDI
                    ! DEC ESI
                    ! jnz NextByte
                    ! xor ecx, &hffffffff
                    ! mov seed2, ecx
                    ! bswap ecx
                    ! mov eax, s1
                    ! mov ebx, L1
                    ! dec ebx
                    ! shl ebx, 2
                    ! mov [eax+ebx], ecx
                    ! popfd
                    ! popad
                    sptr = sptr + L4
                next
                function = cvq(s1)
                exit function
            Crc32Table:
            ! dd &H000000000&, &H077073096&, &H0EE0E612C&, &H0990951BA&
            ! dd &H0076DC419&, &H0706AF48F&, &H0E963A535&, &H09E6495A3&
            ! dd &H00EDB8832&, &H079DCB8A4&, &H0E0D5E91E&, &H097D2D988&
            ! dd &H009B64C2B&, &H07EB17CBD&, &H0E7B82D07&, &H090BF1D91&
            ! dd &H01DB71064&, &H06AB020F2&, &H0F3B97148&, &H084BE41DE&
            ! dd &H01ADAD47D&, &H06DDDE4EB&, &H0F4D4B551&, &H083D385C7&
            ! dd &H0136C9856&, &H0646BA8C0&, &H0FD62F97A&, &H08A65C9EC&
            ! dd &H014015C4F&, &H063066CD9&, &H0FA0F3D63&, &H08D080DF5&
            ! dd &H03B6E20C8&, &H04C69105E&, &H0D56041E4&, &H0A2677172&
            ! dd &H03C03E4D1&, &H04B04D447&, &H0D20D85FD&, &H0A50AB56B&
            ! dd &H035B5A8FA&, &H042B2986C&, &H0DBBBC9D6&, &H0ACBCF940&
            ! dd &H032D86CE3&, &H045DF5C75&, &H0DCD60DCF&, &H0ABD13D59&
            ! dd &H026D930AC&, &H051DE003A&, &H0C8D75180&, &H0BFD06116&
            ! dd &H021B4F4B5&, &H056B3C423&, &H0CFBA9599&, &H0B8BDA50F&
            ! dd &H02802B89E&, &H05F058808&, &H0C60CD9B2&, &H0B10BE924&
            ! dd &H02F6F7C87&, &H058684C11&, &H0C1611DAB&, &H0B6662D3D&
            ! dd &H076DC4190&, &H001DB7106&, &H098D220BC&, &H0EFD5102A&
            ! dd &H071B18589&, &H006B6B51F&, &H09FBFE4A5&, &H0E8B8D433&
            ! dd &H07807C9A2&, &H00F00F934&, &H09609A88E&, &H0E10E9818&
            ! dd &H07F6A0DBB&, &H0086D3D2D&, &H091646C97&, &H0E6635C01&
            ! dd &H06B6B51F4&, &H01C6C6162&, &H0856530D8&, &H0F262004E&
            ! dd &H06C0695ED&, &H01B01A57B&, &H08208F4C1&, &H0F50FC457&
            ! dd &H065B0D9C6&, &H012B7E950&, &H08BBEB8EA&, &H0FCB9887C&
            ! dd &H062DD1DDF&, &H015DA2D49&, &H08CD37CF3&, &H0FBD44C65&
            ! dd &H04DB26158&, &H03AB551CE&, &H0A3BC0074&, &H0D4BB30E2&
            ! dd &H04ADFA541&, &H03DD895D7&, &H0A4D1C46D&, &H0D3D6F4FB&
            ! dd &H04369E96A&, &H0346ED9FC&, &H0AD678846&, &H0DA60B8D0&
            ! dd &H044042D73&, &H033031DE5&, &H0AA0A4C5F&, &H0DD0D7CC9&
            ! dd &H05005713C&, &H0270241AA&, &H0BE0B1010&, &H0C90C2086&
            ! dd &H05768B525&, &H0206F85B3&, &H0B966D409&, &H0CE61E49F&
            ! dd &H05EDEF90E&, &H029D9C998&, &H0B0D09822&, &H0C7D7A8B4&
            ! dd &H059B33D17&, &H02EB40D81&, &H0B7BD5C3B&, &H0C0BA6CAD&
            ! dd &H0EDB88320&, &H09ABFB3B6&, &H003B6E20C&, &H074B1D29A&
            ! dd &H0EAD54739&, &H09DD277AF&, &H004DB2615&, &H073DC1683&
            ! dd &H0E3630B12&, &H094643B84&, &H00D6D6A3E&, &H07A6A5AA8&
            ! dd &H0E40ECF0B&, &H09309FF9D&, &H00A00AE27&, &H07D079EB1&
            ! dd &H0F00F9344&, &H08708A3D2&, &H01E01F268&, &H06906C2FE&
            ! dd &H0F762575D&, &H0806567CB&, &H0196C3671&, &H06E6B06E7&
            ! dd &H0FED41B76&, &H089D32BE0&, &H010DA7A5A&, &H067DD4ACC&
            ! dd &H0F9B9DF6F&, &H08EBEEFF9&, &H017B7BE43&, &H060B08ED5&
            ! dd &H0D6D6A3E8&, &H0A1D1937E&, &H038D8C2C4&, &H04FDFF252&
            ! dd &H0D1BB67F1&, &H0A6BC5767&, &H03FB506DD&, &H048B2364B&
            ! dd &H0D80D2BDA&, &H0AF0A1B4C&, &H036034AF6&, &H041047A60&
            ! dd &H0DF60EFC3&, &H0A867DF55&, &H0316E8EEF&, &H04669BE79&
            ! dd &H0CB61B38C&, &H0BC66831A&, &H0256FD2A0&, &H05268E236&
            ! dd &H0CC0C7795&, &H0BB0B4703&, &H0220216B9&, &H05505262F&
            ! dd &H0C5BA3BBE&, &H0B2BD0B28&, &H02BB45A92&, &H05CB36A04&
            ! dd &H0C2D7FFA7&, &H0B5D0CF31&, &H02CD99E8B&, &H05BDEAE1D&
            ! dd &H09B64C2B0&, &H0EC63F226&, &H0756AA39C&, &H0026D930A&
            ! dd &H09C0906A9&, &H0EB0E363F&, &H072076785&, &H005005713&
            ! dd &H095BF4A82&, &H0E2B87A14&, &H07BB12BAE&, &H00CB61B38&
            ! dd &H092D28E9B&, &H0E5D5BE0D&, &H07CDCEFB7&, &H00BDBDF21&
            ! dd &H086D3D2D4&, &H0F1D4E242&, &H068DDB3F8&, &H01FDA836E&
            ! dd &H081BE16CD&, &H0F6B9265B&, &H06FB077E1&, &H018B74777&
            ! dd &H088085AE6&, &H0FF0F6A70&, &H066063BCA&, &H011010B5C&
            ! dd &H08F659EFF&, &H0F862AE69&, &H0616BFFD3&, &H0166CCF45&
            ! dd &H0A00AE278&, &H0D70DD2EE&, &H04E048354&, &H03903B3C2&
            ! dd &H0A7672661&, &H0D06016F7&, &H04969474D&, &H03E6E77DB&
            ! dd &H0AED16A4A&, &H0D9D65ADC&, &H040DF0B66&, &H037D83BF0&
            ! dd &H0A9BCAE53&, &H0DEBB9EC5&, &H047B2CF7F&, &H030B5FFE9&
            ! dd &H0BDBDF21C&, &H0CABAC28A&, &H053B39330&, &H024B4A3A6&
            ! dd &H0BAD03605&, &H0CDD70693&, &H054DE5729&, &H023D967BF&
            ! dd &H0B3667A2E&, &H0C4614AB8&, &H05D681B02&, &H02A6F2B94&
            ! dd &H0B40BBE37&, &H0C30C8EA1&, &H05A05DF1B&, &H02D02EF8D&
            end function

            ------------------


            [This message has been edited by Clay Clear (edited April 26, 2007).]

            Comment


            • #7
              Clay, the theoretical collision rate is 1 in 2^64.

              However, because of the birthday paradox there is a 50% chance of a collision with 1 in sqrt(pi/2)*2^(blocksize/2).

              For CRC64 we have then a 50% chance with 1 in 5.4x10^9. With CRC32 we have a 50% chance with 1 in 82317.

              Comment


              • #8
                Thanks, David.


                ------------------

                Comment


                • #9
                  Here is another approximation:

                  'Messages' = sqrt( -2^(m+1) x ln(1-probabilty) )

                  where m is the blocksize.

                  So, with m = 32 and probabilty = 50% we get 77162 or 2^16.24

                  Not the same as 82317 but close enough in this game at 2^16.33

                  The frightening thing is with a probability of 25%. In this case we get 49710.

                  So, with four computers having in excess of 49710 files each a CRC32 checksum run may give one machine the thumbs up on a corrupt file.

                  Win98's System File Checker uses CRC32.

                  Not sure what XP uses.


                  [This message has been edited by David Roberts (edited April 26, 2007).]

                  Comment


                  • #10
                    Hmmmm...I've been swearing for a long time that I'd go back to Win98SE
                    in a heartbeat if I had that option (my current box is too modern
                    for it to be feasible - XP is a much better choice). Now I guess
                    I should be glad that I can't. Those kinds of "security holes" (can't
                    think of a proper expression for it) would make me not want to
                    downgrade.


                    ------------------

                    Comment


                    • #11
                      #if 0
                      This is a different version of my crc-64 code that I just whipped
                      up. I don't know if it's really any better than my original posted
                      version. The difference is that it allows, and operates on, a 64-bit
                      seed. So, to my untrained mind, it's closer to a "true" 64-bit
                      CRC algorithm. Again, the code posted here is released to the Public
                      Domain, with the assorted notations I made in my first code posting.
                      #endif

                      Code:
                      function CRCHashquad (byval in1 as string, opt byval vt1 as variant) as quad
                          #register none
                          function = 0
                          if in1 = "" then exit function
                          local seed2 as quad, L as long, L2 as long, L3 as long, L4 as long, L5 as long, L1&
                          local count as long
                          local qptr as dword
                          local count2 as long
                          local count3 as long
                          local count4 as long
                          seed2 = crchashseed(vt1, 8)
                          L = ((len(in1) \ 9) + 1) * 9
                          in1 = in1 + left$(chr$(0 to 20), L - len(in1))    
                          ! pushad
                          ! pushfd
                          ! mov ecx, dword ptr seed2[0]
                          ! mov edx, dword ptr seed2[4]
                          ! xor ecx, &hffffffff
                          ! xor edx, &hffffffff
                          ! mov edi, in1
                          ! MOV ESI, [edi - 4]
                          ! XOR EAX, EAX
                          NextByte:
                          ! MOV AL, cl
                          ! XOR AL, [EDI]
                          ! shrd ecx, edx, 8
                          ! shr edx, 8
                          ! xor ecx, dword ptr crc32table[eax*4]
                          ! xor edx, dword ptr crc32table[eax*4]
                          ! INC EDI
                          ! DEC ESI
                          ! jnz NextByte
                          ! xor ecx, &hffffffff
                          ! xor edx, &hffffffff
                          ! bswap ecx
                          ! bswap edx
                          ! mov dword ptr seed2[0], edx
                          ! mov dword ptr seed2[4], ecx
                          ! popfd
                          ! popad
                          function = seed2
                          exit function
                      Crc32Table:
                      ! dd &H000000000&, &H077073096&, &H0EE0E612C&, &H0990951BA&
                      ! dd &H0076DC419&, &H0706AF48F&, &H0E963A535&, &H09E6495A3&
                      ! dd &H00EDB8832&, &H079DCB8A4&, &H0E0D5E91E&, &H097D2D988&
                      ! dd &H009B64C2B&, &H07EB17CBD&, &H0E7B82D07&, &H090BF1D91&
                      ! dd &H01DB71064&, &H06AB020F2&, &H0F3B97148&, &H084BE41DE&
                      ! dd &H01ADAD47D&, &H06DDDE4EB&, &H0F4D4B551&, &H083D385C7&
                      ! dd &H0136C9856&, &H0646BA8C0&, &H0FD62F97A&, &H08A65C9EC&
                      ! dd &H014015C4F&, &H063066CD9&, &H0FA0F3D63&, &H08D080DF5&
                      ! dd &H03B6E20C8&, &H04C69105E&, &H0D56041E4&, &H0A2677172&
                      ! dd &H03C03E4D1&, &H04B04D447&, &H0D20D85FD&, &H0A50AB56B&
                      ! dd &H035B5A8FA&, &H042B2986C&, &H0DBBBC9D6&, &H0ACBCF940&
                      ! dd &H032D86CE3&, &H045DF5C75&, &H0DCD60DCF&, &H0ABD13D59&
                      ! dd &H026D930AC&, &H051DE003A&, &H0C8D75180&, &H0BFD06116&
                      ! dd &H021B4F4B5&, &H056B3C423&, &H0CFBA9599&, &H0B8BDA50F&
                      ! dd &H02802B89E&, &H05F058808&, &H0C60CD9B2&, &H0B10BE924&
                      ! dd &H02F6F7C87&, &H058684C11&, &H0C1611DAB&, &H0B6662D3D&
                      ! dd &H076DC4190&, &H001DB7106&, &H098D220BC&, &H0EFD5102A&
                      ! dd &H071B18589&, &H006B6B51F&, &H09FBFE4A5&, &H0E8B8D433&
                      ! dd &H07807C9A2&, &H00F00F934&, &H09609A88E&, &H0E10E9818&
                      ! dd &H07F6A0DBB&, &H0086D3D2D&, &H091646C97&, &H0E6635C01&
                      ! dd &H06B6B51F4&, &H01C6C6162&, &H0856530D8&, &H0F262004E&
                      ! dd &H06C0695ED&, &H01B01A57B&, &H08208F4C1&, &H0F50FC457&
                      ! dd &H065B0D9C6&, &H012B7E950&, &H08BBEB8EA&, &H0FCB9887C&
                      ! dd &H062DD1DDF&, &H015DA2D49&, &H08CD37CF3&, &H0FBD44C65&
                      ! dd &H04DB26158&, &H03AB551CE&, &H0A3BC0074&, &H0D4BB30E2&
                      ! dd &H04ADFA541&, &H03DD895D7&, &H0A4D1C46D&, &H0D3D6F4FB&
                      ! dd &H04369E96A&, &H0346ED9FC&, &H0AD678846&, &H0DA60B8D0&
                      ! dd &H044042D73&, &H033031DE5&, &H0AA0A4C5F&, &H0DD0D7CC9&
                      ! dd &H05005713C&, &H0270241AA&, &H0BE0B1010&, &H0C90C2086&
                      ! dd &H05768B525&, &H0206F85B3&, &H0B966D409&, &H0CE61E49F&
                      ! dd &H05EDEF90E&, &H029D9C998&, &H0B0D09822&, &H0C7D7A8B4&
                      ! dd &H059B33D17&, &H02EB40D81&, &H0B7BD5C3B&, &H0C0BA6CAD&
                      ! dd &H0EDB88320&, &H09ABFB3B6&, &H003B6E20C&, &H074B1D29A&
                      ! dd &H0EAD54739&, &H09DD277AF&, &H004DB2615&, &H073DC1683&
                      ! dd &H0E3630B12&, &H094643B84&, &H00D6D6A3E&, &H07A6A5AA8&
                      ! dd &H0E40ECF0B&, &H09309FF9D&, &H00A00AE27&, &H07D079EB1&
                      ! dd &H0F00F9344&, &H08708A3D2&, &H01E01F268&, &H06906C2FE&
                      ! dd &H0F762575D&, &H0806567CB&, &H0196C3671&, &H06E6B06E7&
                      ! dd &H0FED41B76&, &H089D32BE0&, &H010DA7A5A&, &H067DD4ACC&
                      ! dd &H0F9B9DF6F&, &H08EBEEFF9&, &H017B7BE43&, &H060B08ED5&
                      ! dd &H0D6D6A3E8&, &H0A1D1937E&, &H038D8C2C4&, &H04FDFF252&
                      ! dd &H0D1BB67F1&, &H0A6BC5767&, &H03FB506DD&, &H048B2364B&
                      ! dd &H0D80D2BDA&, &H0AF0A1B4C&, &H036034AF6&, &H041047A60&
                      ! dd &H0DF60EFC3&, &H0A867DF55&, &H0316E8EEF&, &H04669BE79&
                      ! dd &H0CB61B38C&, &H0BC66831A&, &H0256FD2A0&, &H05268E236&
                      ! dd &H0CC0C7795&, &H0BB0B4703&, &H0220216B9&, &H05505262F&
                      ! dd &H0C5BA3BBE&, &H0B2BD0B28&, &H02BB45A92&, &H05CB36A04&
                      ! dd &H0C2D7FFA7&, &H0B5D0CF31&, &H02CD99E8B&, &H05BDEAE1D&
                      ! dd &H09B64C2B0&, &H0EC63F226&, &H0756AA39C&, &H0026D930A&
                      ! dd &H09C0906A9&, &H0EB0E363F&, &H072076785&, &H005005713&
                      ! dd &H095BF4A82&, &H0E2B87A14&, &H07BB12BAE&, &H00CB61B38&
                      ! dd &H092D28E9B&, &H0E5D5BE0D&, &H07CDCEFB7&, &H00BDBDF21&
                      ! dd &H086D3D2D4&, &H0F1D4E242&, &H068DDB3F8&, &H01FDA836E&
                      ! dd &H081BE16CD&, &H0F6B9265B&, &H06FB077E1&, &H018B74777&
                      ! dd &H088085AE6&, &H0FF0F6A70&, &H066063BCA&, &H011010B5C&
                      ! dd &H08F659EFF&, &H0F862AE69&, &H0616BFFD3&, &H0166CCF45&
                      ! dd &H0A00AE278&, &H0D70DD2EE&, &H04E048354&, &H03903B3C2&
                      ! dd &H0A7672661&, &H0D06016F7&, &H04969474D&, &H03E6E77DB&
                      ! dd &H0AED16A4A&, &H0D9D65ADC&, &H040DF0B66&, &H037D83BF0&
                      ! dd &H0A9BCAE53&, &H0DEBB9EC5&, &H047B2CF7F&, &H030B5FFE9&
                      ! dd &H0BDBDF21C&, &H0CABAC28A&, &H053B39330&, &H024B4A3A6&
                      ! dd &H0BAD03605&, &H0CDD70693&, &H054DE5729&, &H023D967BF&
                      ! dd &H0B3667A2E&, &H0C4614AB8&, &H05D681B02&, &H02A6F2B94&
                      ! dd &H0B40BBE37&, &H0C30C8EA1&, &H05A05DF1B&, &H02D02EF8D&
                      end function

                      ------------------




                      [This message has been edited by Clay Clear (edited April 27, 2007).]

                      Comment


                      • #12
                        Thanks for the revised code, Clay.

                        David, your explanation of the statistical principles behind collisions was most useful. I was puzzled by the fact that the webpage I cite above found (if I recall correctly) 30K collisions in 18M unique documents with CRC32. I assumed it was an artifact of the CRC32 algo. Thanks, and happy (un)birthday!

                        Eddy, I'll try your suggestion too -- it seems to make sense. Now it all comes down to speed trials!

                        Regards,
                        Bill

                        ------------------

                        Comment


                        • #13

                          I'm not sure if the following has any merit or not, yet.

                          (1) Given two messages, whether they be strings, files or whatever, then if they are the same their respective checksums will be the same.

                          (2) Given two checksums which are different then their respective messages will be different else we contradict (1)

                          (3) Given two messages which are different then their respective checksums will be different unless they collide. We could write that as given two checksums which are the same then their respective messages will be the same unless the checksums have collided.

                          If (2) obtains then we have a conclusion without further ado.

                          With (3) we have a problem in that we don't know if a collision has occurred or not.

                          Suppose we introduce a second layer of checksums via a different seed.

                          If this second layer differed then, from (2), we have differing messages. This contradicts the first layer so the first layer must have been a collision.

                          From a computational view point a second layer will take twice the storage but may be the same as a 'higher' checksum, for example from CRC32 to CRC64. We must also check whether two 'lower' checksum calculations are faster than one 'higher' calculation.

                          However, much depends upon the environment. If we are checking files and expect few changes then the second layer will be brought into account more often than not. On the other hand, an environment where we expect many changes then the second layer will be brought into account less often.

                          This concept is not fool-proof as we could have a second layer collision resulting in agreement with the first layer which figured no change when, in fact, there was one.

                          I haven't managed to crack the maths yet: One attempt suggested that the concept pushed the CRC64 envelope and another suggested that we only halved the probability, which, if true, isn't much to write home about.

                          If the concept has any merit then it could be extended to MD5, SHA1 and so on. We are not talking different seeds now but different keys so we are talking HMAC then.



                          [This message has been edited by David Roberts (edited May 03, 2007).]

                          Comment


                          • #14
                            Originally posted by Greg Turgeon:
                            The only code I found (years ago now, when I thought I'd need
                            such a capability for a project at the time):
                            http://lists.boost.org/Archives/boost/2002/03/26953.php

                            I never ported it to PB, but doing so should be easy enough
                            to make experimenting worth the trouble.
                            FYI
                            In the event someone wants more info on CRC, error checking,
                            (s)he might take a look at a copy of a document referenced in
                            the boost.org article which has a link that is no longer useful
                            to: "A Painless Guide To CRC Error Detection Algorithms",
                            by Ross Williams, published 19 August 1993. Here is one link
                            to that document that is still valid: http://www.geocities.com/SiliconVall...s/8659/crc.htm
                            The article was located by searching Beaucoup.COM, using "CRC".

                            Although the article doesn't go into CRC-64, it is well worth
                            spending some time developing some understanding of the principles
                            and following through the author's development of an example. Having
                            a foot in the door, so to speak, by understanding the process,
                            will allow one to create the ultimate CRC-xxx (xxx, is whatever
                            you choose).



                            ------------------
                            =DM=
                            =DM=

                            Comment

                            Working...
                            X