Bitcoin Forum
October 14, 2026, 06:07:54 PM *
News: Serious possible issue involving Ledger hardware wallets and CryptoBilis
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: DB 4.8.30 shipped a NON-STANDARD SHA-1  (Read 181 times)
SleepycatSwap (OP)
Newbie
*
Offline

Activity: 6
Merit: 22


View Profile
October 10, 2026, 09:51:00 AM
Merited by NotATether (5), ABCbits (2), Cricktor (2), nc50lc (1), vjudeu (1), stwenhao (1), athanred (1)
 #1

Berkeley DB 4.8.30 ships a non-standard SHA-1 (and it changes with the machine's endianness)

Hi Bitcointalk.  I got curious about the encryption built into Berkeley DB, the DB_ENCRYPT feature you get with --enable-cryptography, and whether anyone in the early days ever used it to encrypt wallet files or other bitcoin data. BDB 4.8.30 is the version that stuck around the bitcoin world for years, so I went digging through its crypto code. I found something that would trip up anyone trying to decrypt that kind of data today, so I'm writing it up in case someone is sitting on an old encrypted database and can't get in.

TL;DR
The SHA-1 compiled into Berkeley DB 4.8.30 (hmac/sha1.c) is not SHA-1. A one-line C operator-precedence bug in the blk0 macro corrupts the first 16 rounds, so SHA1("abc") comes out as c8afef54... instead of the textbook a9993e36.... It round-trips fine inside BDB, so almost nobody noticed. Two things go wrong because of it:
  • No standard tool (OpenSSL, Python hashlib, hashcat, any SHA-1 library) can reproduce BDB's HMAC/MAC or its AES key derivation. If you're trying to crack or recover a BDB-encrypted blob with a normal SHA-1, you will never match.
  • The broken hash is architecture-dependent. A database encrypted with BDB's own DB_ENCRYPT on a little-endian box (x86) produces a different key and MAC than it would on a big-endian box, so the file can be permanently unreadable on the other architecture even with the correct password.
Worth saying up front: this is an interoperability and data-lock-in defect, not a cryptographic weakness, and it does not affect Bitcoin Core wallets (Core doesn't use BDB's built-in encryption, see the Scope section). It only bites code that used Berkeley DB's own DB_ENCRYPT.

The bug
In db-4.8.30/hmac/sha1.c around line 88:

Source : https://download.oracle.com/berkeley-db/db-4.8.30.tar.gz

Code:
#define blk0(i) is_bigendian ? block->l[i] : \
    (block->l[i] = (rol(block->l[i],24)&0xFF00FF00) \
    |(rol(block->l[i],8)&0x00FF00FF))

blk0() is meant to do one small thing. On a little-endian CPU it byte-swaps the i-th 32-bit message word into the big-endian order SHA-1 needs, and on a big-endian CPU it returns it unchanged. It gets used inside the first round macro R0:

Code:
#define R0(v,w,x,y,z,i) z+=((w&(x^y))^y)+blk0(i)+0x5A827999+rol(v,5); w=rol(w,30);

Because blk0 has no parentheses around it, after macro expansion R0 becomes:

Code:
z += ((w&(x^y))^y) + is_bigendian ? block->l[i]
                                  : (block->l[i]=SWAP) + 0x5A827999 + rol(v,5);

C precedence is + above ?: above +=. With no parentheses the compiler reads it as:

Code:
z += ( ((w&(x^y))^y) + is_bigendian )      // the whole left side is the CONDITION
       ? ( block->l[i] )                    // true  branch
       : ( (block->l[i]=SWAP) + 0x5A827999 + rol(v,5) );   // false branch

So in the 16 rounds that use blk0, on the branch that runs nearly every time, three things go missing:
  • the nonlinear term ((w&(x^y))^y) gets swallowed into the condition and is never added to the state,
  • the round constant 0x5A827999 is dropped,
  • rol(v,5) is dropped,
  • and the message word comes back without the byte-swap.
Only the first 16 rounds are affected, since R1 to R4 use blk() which is parenthesized correctly, but trashing the first 16 rounds is enough to change the whole 80-round digest.

You can see it in one line
Compiling Berkeley DB's own unmodified sha1.c on x86 (little-endian):
Code:
SHA1("abc")              = c8afef5423a485a54f7ecba8bc778ce33e553f53   (standard: a9993e36...)
SHA1("")                 = a646ef710952b006be9498e2111045162233ef67   (standard: da39a3ee...)
HMAC(0x0b x20,"Hi There")= ac671d518a7334841d67a3c8e76600153401eb4e   (RFC2202: b6173186...)
Put parentheses around the blk0 ternary (the one-character fix) and the same file reproduces the exact FIPS-180-1 and RFC 2202 vectors. That proves the macro is the only thing wrong.

It is not weak, it is just a different hash
Before anyone panics, this does not make anything crackable. Over 300k random inputs the broken hash is statistically indistinguishable from real SHA-1:
Code:
                 out-bit bias (want 50%)      avalanche /160 (want ~80)
BDB broken       50.00% (49.74..50.25)        79.99
standard SHA-1   50.00% (49.78..50.21)        79.99
Rounds 16 to 79 still mix everything properly, so what you get is a perfectly good 160-bit hash. It just isn't SHA-1, and nothing else computes it. No reduced security, full key entropy. The damage is interoperability, not security.

The part that actually loses data
Real SHA-1 gives the same answer on every machine. The broken one does not. Its dominant branch forwards the raw machine-order word without normalizing it, so a little-endian build and a big-endian build end up computing two different functions:

Code:
                     SHA1("abc")
little-endian (x86)  c8afef5423a485a54f7ecba8bc778ce33e553f53
big-endian  (s390x)  3d11f750bf8d57b7b574d7cd95f8de44b52a9bbf

Over 20,000 random inputs the little-endian and big-endian digests disagreed on all 20,000. The control, real SHA-1, disagreed on 0 out of 2,000. To be sure the big-endian value wasn't just my model, I cross-compiled Berkeley DB's unmodified sha1.c for IBM s390x and ran it under qemu. It produced exactly 3d11f750... for "abc", matching.

Why this makes data unreadable across machines
BDB's encryption builds everything out of this SHA-1:
  • AES-128 key = BDB_SHA1( pw + "encryption and decryption key value magic" + pw )[:16]
  • MAC key = BDB_SHA1( pw + "mac derivation key magic value" + pw )
  • page MAC = HMAC-BDB_SHA1( mac_key, page )
Because the SHA-1 itself changes with the architecture, a database written with DB_ENCRYPT on a little-endian server derives a different AES key and MAC than the same password would on a big-endian server. Open it on the other machine and the page MAC check fails, BDB reports it as a checksum or corruption error, and the plaintext decrypts to garbage, even with the correct password. It stays self-consistent only inside one endianness, which is exactly why it works fine until the day you move the file.

Scope, who is and isn't affected
  • Affected: anything that used Berkeley DB's own encryption (DB_ENCRYPT, builds with --enable-cryptography), whether directly through the C API or through some app or tool that turned it on. Especially if the data ever moved between a little-endian and a big-endian machine, or if you're trying to re-derive the key or MAC with a standard SHA-1.
  • Not affected: Bitcoin Core wallet.dat. Core never used Berkeley DB's built-in encryption. Wallet secrets are encrypted at the application layer with its own AES-256-CBC and an OpenSSL based key derivation, so this code path is never touched. Ordinary unencrypted BDB files don't use SHA-1 for their page checksums either (they use a different function), so this only shows up when BDB's own crypto is switched on.

If you're stuck, how to get your data back
  • Open the database with a BDB build of the same endianness as the machine that wrote it. If it was written on x86, read it on an x86 box. Don't just add the parentheses and expect to read old data, because a corrected SHA-1 produces standard digests and will not match what's already stored.
  • If you're writing a recovery or cracking tool, you have to reproduce BDB's broken SHA-1 exactly, matching the endianness of the machine that wrote the file, not OpenSSL or standard SHA-1. That one detail is the reason off-the-shelf tools never match a BDB-encrypted blob.
  • If all you want is for new databases to be portable, parenthesize blk0 and rebuild, but migrate your old data out first with a matching-endianness build.

Reproduce it yourself
  • Grab db-4.8.30 and compile hmac/sha1.c on its own, then hash "abc". You get c8afef54... on x86. Add the parentheses to blk0 and you get a9993e36....
  • Cross-compile the same file for a big-endian target like s390x under qemu and "abc" becomes 3d11f750....

I have a small test harness that does all of this side by side the unmodified file against the one-character fix, a round-by-round trace of where it goes wrong, the little vs big endian divergence test, and the s390x build. Happy to share it if anyone wants to check my work. If this bit you, reply with your architecture and how the data was originally made and I'll try to help. The fix is almost always to read it back on the same endianness it was written on.

Interesting no one found this at the time but again this would of been a non-standard thing to do but the options was there and I am sure some people may of used this option on mining servers back in the day.

Regards

SleepycatSwap

** Note I DID use AI to help format the post so it's clear where the issue is but the research and code was hand balled and tested.
NotATether
Legendary
*
Offline

Activity: 2478
Merit: 10400


┻┻ ︵㇏(°□°㇏)


View Profile WWW
October 10, 2026, 10:44:57 AM
 #2

I don't think people should be using such cryptographic primitives provided by database in the first place.

BDB has also never been audited like eg, OpenSSL.

So it would be very foolish to make applications depend on this specific feature.

▄▄████████████████████▄▄
▄███████▀▀██████▀▀███████▄
█████▀██████████████▀█████
████████▄▄██████▄▄████▀███

██████████████████████████
██▄▄██████████████▄▄██████
██▀▀██████████████████▄▄██
██████▀▀██████████████▀▀██
██████████████████████████
███▄████▀▀██████▀▀████████
█████▄██████████████▄█████
▀███████▄▄██████▄▄███████▀
▀▀████████████████████▀▀
 
 DΞX.fo 
▄▄██████
█████████
██████████
██████████
██████████
█████████
▀▀██████

▄███████
▄██████████
████████████
█████████████
█████████████
|
▄▄█
▄████▀
▄███▀█▄
▄██▀█▄██
█████▀▀█
████████
████████
▀██▄████
▄████▄▄█
▄█████▀███
▄█████▀████▀
█████▀███████
▀██▀█████████
|..BTC......XMR...
..USDT.....LTC...
....Fees  0.8%.....
athanred
Full Member
***
Offline

Activity: 194
Merit: 354


View Profile
October 11, 2026, 02:36:13 AM
Merited by NotATether (3), nc50lc (1)
 #3

Quote
in case someone is sitting on an old encrypted database and can't get in
Seems to be unlikely, but it is a nice finding, if it is true. I will try to verify it.

Hashes reproduced by me so far:
Code:
SHA1("abc")=a9993e364706816aba3e25717850c26c9cd0d89d
SHA1("")=da39a3ee5e6b4b0d3255bfef95601890afd80709
HMAC-SHA1(0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b,"Hi There")=b617318655057264e28bc0b6fb378c8ef146be00
I will try to verify bugged ones later, but they seems to be correct.

I think no users are affected, however, maybe it will help uncover the mystery behind the low x-value in secp256k1 generator, or some elliptic curve seeds. If they used some old code, then SHA1("Base point"||some_data) can be non-standard, which could explain, why nobody reproduced these seeds so far.
SleepycatSwap (OP)
Newbie
*
Offline

Activity: 6
Merit: 22


View Profile
October 11, 2026, 11:55:04 AM
Merited by NotATether (3), vjudeu (1), stwenhao (1)
 #4

Thankis but did you run those with a normal SHA1 though, hashlib or openssl, so of course they match the textbook. That was never the part I said was broken.

The broken one is the SHA1 that Berkeley DB compiles out of its own hmac/sha1.c.

That code never talks to anything outside BDB, so it never had to agree with a real SHA1, and that's exactly why it went unnoticed this long. Run "abc" through that file instead of openssl and you get a different digest:

Code:
                           BDB 4.8.30 (own sha1.c)                   standard SHA1
SHA1("abc")                c8afef5423a485a54f7ecba8bc778ce33e553f53  a9993e364706816aba3e25717850c26c9cd0d89d
SHA1("")                   a646ef710952b006be9498e2111045162233ef67  da39a3ee5e6b4b0d3255bfef95601890afd80709
HMAC(0x0b x20,"Hi There")  ac671d518a7334841d67a3c8e76600153401eb4e  b617318655057264e28bc0b6fb378c8ef146be00

Easiest way to see it: pull hmac/sha1.c out of db-4.8.30, compile it on its own, hash "abc", and you get c8afef54. Then put parentheses around the blk0 ternary and rebuild.

The same file now prints a9993e36, da39a3ee and the right RFC2202 HMAC. One change, nothing else touched, so it's the macro.

The why, if you want it: blk0 isn't parenthesized, and + binds tighter than ?: which binds tighter than +=, so R0 actually compiles as:

Code:
z += ( ((w&(x^y))^y) + is_bigendian ) ? block->l[i] : (block->l[i]=SWAP) + 0x5A827999 + rol(v,5);

So on the branch that runs basically every round, the F term, the 0x5A827999 and the rol(v,5) all just vanish and the word never gets byte-swapped. Only the 16 R0 rounds hit it, R1 through R4 use blk() which is fine, but that's plenty to wreck the digest.

@NotATether, no argument, nobody should be leaning on BDB's crypto. But some people did. DB_ENCRYPT was the only at-rest option on server builds before Core added wallet encryption in 0.4, and those files are still out there. That's who this is for, and it's why a standard SHA1 never matches them.

Got the harness if anyone wants to run it themselves, the unmodified file vs the one-char fix, a round trace, LE vs BE, and the s390x build.
SleepycatSwap (OP)
Newbie
*
Offline

Activity: 6
Merit: 22


View Profile
October 11, 2026, 05:25:46 PM
Merited by stwenhao (1)
 #5

Quote
in case someone is sitting on an old encrypted database and can't get in
I think no users are affected, however, maybe it will help uncover the mystery behind the low x-value in secp256k1 generator, or some elliptic curve seeds. If they used some old code, then SHA1("Base point"||some_data) can be non-standard, which could explain, why nobody reproduced these seeds so far.

I don't think it reaches the secp256k1 seeds. This bug is entirely inside Berkeley DB's own sha1.c and nothing in the curve generation ever calls that file, so the low x-value and the unreproduced seeds are a separate rabbit hole. Different code path, different story.

Where I do think people got caught is the early users. If someone turned on the database encryption back then and ran the tools against it, everything looked fine for as long as they stayed on the same build. The broken digest was at least consistent with itself, so it opened and closed without complaint. The trouble only shows up later, when they move to a new machine or a rebuilt binary and the hash no longer comes out the same. That is when the file suddenly won't open, and from the outside it looks like a corrupt wallet rather than a hashing bug.

It's an unseen failure for exactly that reason. Nobody would have noticed it in normal day to day use, so there could easily be old miners or early users sitting on a file they can't get back into and no idea why.

Worth remembering the options at the time too. If you wanted to protect a wallet the usual route was OpenSSL or PGP on the file yourself, but the DB that shipped with Bitcoin had encryption built in, so we can't rule out that some people leaned on that instead and are stuck now.

Scope wise it's narrow. It only touches builds with crypto enabled where the SHA-1 or HMAC functions actually got used. If that never happened on your setup there's nothing here for you. But for the handful it did happen to, this is probably the reason the digest breaks the moment they change systems.
TheButterZone
Legendary
*
Offline

Activity: 3290
Merit: 1146


RIP Mommy


View Profile WWW
October 11, 2026, 05:37:31 PM
 #6

So now it's a matter of trying to programmatically find everyone who reported wallets from this time being broken, and then actually managing to make contact & direct them to this thread?

Some may never come back to wherever they posted, or even have changed/lost their email address, so even notifications they enabled would fail.

SleepycatSwap (OP)
Newbie
*
Offline

Activity: 6
Merit: 22


View Profile
October 11, 2026, 05:54:11 PM
Merited by ABCbits (1), stwenhao (1)
 #7

So now it's a matter of trying to programmatically find everyone who reported wallets from this time being broken, and then actually managing to make contact & direct them to this thread?

Some may never come back to wherever they posted, or even have changed/lost their email address, so even notifications they enabled would fail.

In a perfect world, I posted it just on the off chance there is still someone sitting on such a DB or wallet from the period that might think it's broken but it's not.

Historical bug, but matters if bitcoin was built with those flags enabled on the DB so best to post it on the off-chance it can help someone.
athanred
Full Member
***
Offline

Activity: 194
Merit: 354


View Profile
October 13, 2026, 01:05:23 PM
Merited by SleepycatSwap (1)
 #8

Finally reproduced the buggy hash with string "abc". Some example:
Code:
#include <stdint.h>
#include <stdio.h>
#include <string.h>

typedef struct
{
    uint32_t state[5];
    uint32_t count[2];
    unsigned char buffer[64];
} SHA1_CTX;

#define rol(value,bits) (((value)<<(bits))|((value)>>(32-(bits))))
#define blk0(i) is_bigendian?block->l[i]:(block->l[i]=(rol(block->l[i],24)&0xff00ff00)|(rol(block->l[i],8)&0x00ff00ff))
#define blk(i) (block->l[i&15]=rol(block->l[(i+13)&15]^block->l[(i+8)&15]^block->l[(i+2)&15]^block->l[i&15],1))
#define R0(v,w,x,y,z,i) z+=((w&(x^y))^y)+blk0(i)+0x5a827999+rol(v,5);w=rol(w,30);
#define R1(v,w,x,y,z,i) z+=((w&(x^y))^y)+blk(i)+0x5a827999+rol(v,5);w=rol(w,30);
#define R2(v,w,x,y,z,i) z+=(w^x^y)+blk(i)+0x6ed9eba1+rol(v,5);w=rol(w,30);
#define R3(v,w,x,y,z,i) z+=(((w|x)&y)|(w&x))+blk(i)+0x8f1bbcdc+rol(v,5);w=rol(w,30);
#define R4(v,w,x,y,z,i) z+=(w^x^y)+blk(i)+0xca62c1d6+rol(v,5);w=rol(w,30);

void __db_SHA1Transform(uint32_t* state,unsigned char* buffer)
{
    int is_bigendian=0; //use zero or one
    typedef union
    {
        unsigned char c[64];
        uint32_t l[16];
    } CHAR64LONG16;
    unsigned char workspace[64];
    CHAR64LONG16* block=(CHAR64LONG16*)workspace;
    memcpy(block,buffer,64);

    uint32_t a=state[0];
    uint32_t b=state[1];
    uint32_t c=state[2];
    uint32_t d=state[3];
    uint32_t e=state[4];

    R0(a,b,c,d,e, 0); R0(e,a,b,c,d, 1); R0(d,e,a,b,c, 2); R0(c,d,e,a,b, 3);
    R0(b,c,d,e,a, 4); R0(a,b,c,d,e, 5); R0(e,a,b,c,d, 6); R0(d,e,a,b,c, 7);
    R0(c,d,e,a,b, 8); R0(b,c,d,e,a, 9); R0(a,b,c,d,e,10); R0(e,a,b,c,d,11);
    R0(d,e,a,b,c,12); R0(c,d,e,a,b,13); R0(b,c,d,e,a,14); R0(a,b,c,d,e,15);
    R1(e,a,b,c,d,16); R1(d,e,a,b,c,17); R1(c,d,e,a,b,18); R1(b,c,d,e,a,19);
    R2(a,b,c,d,e,20); R2(e,a,b,c,d,21); R2(d,e,a,b,c,22); R2(c,d,e,a,b,23);
    R2(b,c,d,e,a,24); R2(a,b,c,d,e,25); R2(e,a,b,c,d,26); R2(d,e,a,b,c,27);
    R2(c,d,e,a,b,28); R2(b,c,d,e,a,29); R2(a,b,c,d,e,30); R2(e,a,b,c,d,31);
    R2(d,e,a,b,c,32); R2(c,d,e,a,b,33); R2(b,c,d,e,a,34); R2(a,b,c,d,e,35);
    R2(e,a,b,c,d,36); R2(d,e,a,b,c,37); R2(c,d,e,a,b,38); R2(b,c,d,e,a,39);
    R3(a,b,c,d,e,40); R3(e,a,b,c,d,41); R3(d,e,a,b,c,42); R3(c,d,e,a,b,43);
    R3(b,c,d,e,a,44); R3(a,b,c,d,e,45); R3(e,a,b,c,d,46); R3(d,e,a,b,c,47);
    R3(c,d,e,a,b,48); R3(b,c,d,e,a,49); R3(a,b,c,d,e,50); R3(e,a,b,c,d,51);
    R3(d,e,a,b,c,52); R3(c,d,e,a,b,53); R3(b,c,d,e,a,54); R3(a,b,c,d,e,55);
    R3(e,a,b,c,d,56); R3(d,e,a,b,c,57); R3(c,d,e,a,b,58); R3(b,c,d,e,a,59);
    R4(a,b,c,d,e,60); R4(e,a,b,c,d,61); R4(d,e,a,b,c,62); R4(c,d,e,a,b,63);
    R4(b,c,d,e,a,64); R4(a,b,c,d,e,65); R4(e,a,b,c,d,66); R4(d,e,a,b,c,67);
    R4(c,d,e,a,b,68); R4(b,c,d,e,a,69); R4(a,b,c,d,e,70); R4(e,a,b,c,d,71);
    R4(d,e,a,b,c,72); R4(c,d,e,a,b,73); R4(b,c,d,e,a,74); R4(a,b,c,d,e,75);
    R4(e,a,b,c,d,76); R4(d,e,a,b,c,77); R4(c,d,e,a,b,78); R4(b,c,d,e,a,79);

    state[0]+=a;
    state[1]+=b;
    state[2]+=c;
    state[3]+=d;
    state[4]+=e;

    a=b=c=d=e=0;
}

void __db_SHA1Init(SHA1_CTX* context)
{
    context->state[0]=0x67452301;
    context->state[1]=0xefcdab89;
    context->state[2]=0x98badcfe;
    context->state[3]=0x10325476;
    context->state[4]=0xc3d2e1f0;
    context->count[0]=context->count[1]=0;
}

void __db_SHA1Update(SHA1_CTX* context,unsigned char* data,size_t len)
{
    uint32_t i;
    uint32_t j=(context->count[0]>>3)&63;
    if((context->count[0]+=(uint32_t)len<<3)<(len<<3))
    {
        ++context->count[1];
    }
    context->count[1]+=(uint32_t)(len>>29);
    if((j+len)>63)
    {
        memcpy(&context->buffer[j],data,(i=64-j));
        __db_SHA1Transform(context->state,context->buffer);
        for(;i+63<len;i+=64)
        {
            __db_SHA1Transform(context->state,&data[i]);
        }
        j=0;
    }
    else i=0;
    memcpy(&context->buffer[j],&data[i],len-i);
}

void __db_SHA1Final(unsigned char* digest,SHA1_CTX* context)
{
    uint32_t i;
    unsigned char finalcount[8];
    for(i=0;i<8;++i)
    {
        finalcount[i]=(unsigned char)((context->count[(i>=4?0:1)]>>((3-(i&3))*8))&255);
    }
    __db_SHA1Update(context,(unsigned char*)"\200",1);
    while((context->count[0]&504)!=448)
    {
        __db_SHA1Update(context,(unsigned char *)"\0",1);
    }
    __db_SHA1Update(context,finalcount,8);
    for(i=0;i<20;++i)
    {
        digest[i]=(unsigned char)((context->state[i>>2]>>((3-(i&3))*8))&255);
    }
    i=0;
    memset(context->buffer,0,64);
    memset(context->state,0,20);
    memset(context->count,0,8);
    memset(finalcount,0,8);
    __db_SHA1Transform(context->state,context->buffer);
}

int main(void)
{
    SHA1_CTX sha;
    uint8_t results[20];
    char* buf="abc";
    int n=strlen(buf);
    __db_SHA1Init(&sha);
    __db_SHA1Update(&sha,(uint8_t*)buf,n);
    __db_SHA1Final(results,&sha);
    printf("0x");
    for(n=0;n<20;++n)
    {
        printf("%02x",results[n]);
    }
    putchar('\n');
    return 0;
}
Output:
Code:
$ gcc main.c
$ ./a.out
0xc8afef5423a485a54f7ecba8bc778ce33e553f53
I will try to analyze it later, round-by-round, to see, what exactly is going on. But it is a good start, to have some "standalone" code, without additional dependencies, which can produce the same results.
SleepycatSwap (OP)
Newbie
*
Offline

Activity: 6
Merit: 22


View Profile
October 13, 2026, 08:43:51 PM
Merited by athanred (1)
 #9

Thanks for building the standalone version. That’s the easiest way for people to check this, because it needs no BDB tree or build system. The c8afef54... output matches what I get from the unmodified file on x86.

A few notes for anyone running it

Check the big-endian result. You hardcoded is_bigendian=0, which is the little-endian path. Set it to 1 and rebuild, and you should get the big-endian value I reported from the s390x run (3d11f750...).

That shows the endian dependence without needing qemu.

The condition in the expanded R0 is F + is_bigendian, and it’s only false when that sum is 0 mod 2^32. That happens roughly once in 2^32 per round, so the “wrong” branch is effectively the only one taken.

When it does hit, the code takes the other branch, which has its own problems, so a trace is worth doing.

I called it a “one-character fix”. That undersold it a bit, the whole ternary needs wrapping, so it’s a pair of parentheses.
I speculated a bit about early users getting locked out.

I should have been clearer that this only matters for people who built BDB with --enable-cryptography and turned on DB_ENCRYPT themselves. As far as I know, stock Bitcoin builds never enabled it, so I’d expect very few real-world victims, if any. This is mostly a “now we know why standard tools never match” finding.

Regards

SleepycatSwap
Danish Ali
Member
**
Offline

Activity: 84
Merit: 173


View Profile
Today at 01:13:35 AM
 #10

Okay, that gives me a better idea of how bad it would be in practice. I'd still count that as separate from the security issue though. Standard avalanche and bit bias results dont establish collision or preimage resistance, so its not clear to me that they prove the modified hash has no effect on security, though I do think the real world impact would probably be negligible.
athanred
Full Member
***
Offline

Activity: 194
Merit: 354


View Profile
Today at 06:58:09 AM
Last edit: Today at 08:17:58 AM by athanred
 #11

Trying to analyze original SHA-1 vs bugged one. Round-by-round comparison, inspired by vjudeu's C++ implementation of SHA-1: https://bitcointalk.org/index.php?topic=293382.msg61865839#msg61865839
Code:
     +----------------------------------------------+----------------------------------------------+
     | original SHA-1                               | bugged SHA-1                                 |
+----+----------------------------------------------+----------------------------------------------+
| 00 | 67452301 efcdab89 98badcfe 10325476 c3d2e1f0 | 67452301 efcdab89 98badcfe 10325476 c3d2e1f0 |
+----+----------------------------------------------+----------------------------------------------+
| 01 | 1fb498b3 67452301 7bf36ae2 98badcfe 10325476 | c3d2e270 67452301 7bf36ae2 98badcfe 10325476 |
| 02 | 5d43e370 1fb498b3 59d148c0 7bf36ae2 98badcfe | 10325476 c3d2e270 59d148c0 7bf36ae2 98badcfe |
| 03 | 158d2f62 5d43e370 c7ed262c 59d148c0 7bf36ae2 | 98badcfe 10325476 30f4b89c 59d148c0 7bf36ae2 |
| 04 | cdecfb5d 158d2f62 1750f8dc c7ed262c 59d148c0 | 7bf36ae2 98badcfe 840c951d 30f4b89c 59d148c0 |
| 05 | 4953565e cdecfb5d 85634bd8 1750f8dc c7ed262c | 59d148c0 7bf36ae2 a62eb73f 840c951d 30f4b89c |
+----+----------------------------------------------+----------------------------------------------+
| 06 | e44ab766 4953565e 737b3ed7 85634bd8 1750f8dc | 30f4b89c 59d148c0 9efcdab8 a62eb73f 840c951d |
| 07 | c09d7f27 e44ab766 9254d597 737b3ed7 85634bd8 | 840c951d 30f4b89c 16745230 9efcdab8 a62eb73f |
| 08 | 87074800 c09d7f27 b912add9 9254d597 737b3ed7 | a62eb73f 840c951d 0c3d2e27 16745230 9efcdab8 |
| 09 | 41376611 87074800 f0275fc9 b912add9 9254d597 | 9efcdab8 a62eb73f 61032547 0c3d2e27 16745230 |
| 10 | cbdbff31 41376611 21c1d200 f0275fc9 b912add9 | 16745230 9efcdab8 e98badcf 61032547 0c3d2e27 |
+----+----------------------------------------------+----------------------------------------------+
| 11 | 40166973 cbdbff31 504dd984 21c1d200 f0275fc9 | 0c3d2e27 16745230 27bf36ae e98badcf 61032547 |
| 12 | adc0e0ca 40166973 72f6ffcc 504dd984 21c1d200 | 61032547 0c3d2e27 059d148c 27bf36ae e98badcf |
| 13 | 84c05eb2 adc0e0ca d0059a5c 72f6ffcc 504dd984 | e98badcf 61032547 c30f4b89 059d148c 27bf36ae |
| 14 | 1512c8b9 84c05eb2 ab703832 d0059a5c 72f6ffcc | 27bf36ae e98badcf d840c951 c30f4b89 059d148c |
| 15 | 40182905 1512c8b9 a13017ac ab703832 d0059a5c | 059d148c 27bf36ae fa62eb73 d840c951 c30f4b89 |
+----+----------------------------------------------+----------------------------------------------+
| 16 | d8fd6547 40182905 4544b22e a13017ac ab703832 | c30f4b89 059d148c 89efcdab fa62eb73 d840c951 |
| 17 | 06bf9173 d8fd6547 50060a41 4544b22e a13017ac | 909ca51d c30f4b89 01674523 89efcdab fa62eb73 |
| 18 | 28a9520e 06bf9173 f63f5951 50060a41 4544b22e | 7261cde1 909ca51d 70c3d2e2 01674523 89efcdab |
| 19 | 0b3088dd 28a9520e c1afe45c f63f5951 50060a41 | 428fc394 7261cde1 64272947 70c3d2e2 01674523 |
| 20 | e758e8da 0b3088dd 8a2a5483 c1afe45c f63f5951 | 0e854e87 428fc394 5c987378 64272947 70c3d2e2 |
+----+----------------------------------------------+----------------------------------------------+
| 21 | 90eb9850 e758e8da 42cc2237 8a2a5483 c1afe45c | 2a78290f 0e854e87 10a3f0e5 5c987378 64272947 |
| 22 | 7dbb787d 90eb9850 b9d63a36 42cc2237 8a2a5483 | 64c503e7 2a78290f c3a153a1 10a3f0e5 5c987378 |
| 23 | 1c64d028 7dbb787d 243ae614 b9d63a36 42cc2237 | 5d8d6a50 64c503e7 ca9e0a43 c3a153a1 10a3f0e5 |
| 24 | 1e97b73a 1c64d028 5f6ede1f 243ae614 b9d63a36 | 9f258096 5d8d6a50 d93140f9 ca9e0a43 c3a153a1 |
| 25 | 62d7f53f 1e97b73a 0719340a 5f6ede1f 243ae614 | 654d74ff 9f258096 17635a94 d93140f9 ca9e0a43 |
+----+----------------------------------------------+----------------------------------------------+
| 26 | 34f3d6d8 62d7f53f 87a5edce 0719340a 5f6ede1f | 349e38cb 654d74ff a7c96025 17635a94 d93140f9 |
| 27 | 4f2ed1c1 34f3d6d8 d8b5fd4f 87a5edce 0719340a | b1b9944e 349e38cb d9535d3f a7c96025 17635a94 |
| 28 | c7b11e2d 4f2ed1c1 0d3cf5b6 d8b5fd4f 87a5edce | 0773d5dc b1b9944e cd278e32 d9535d3f a7c96025 |
| 29 | 874b786f c7b11e2d 53cbb470 0d3cf5b6 d8b5fd4f | aaeb5e89 0773d5dc ac6e6513 cd278e32 d9535d3f |
| 30 | ca4556cb 874b786f 71ec478b 53cbb470 0d3cf5b6 | 0bd35912 aaeb5e89 01dcf577 ac6e6513 cd278e32 |
+----+----------------------------------------------+----------------------------------------------+
| 31 | 6a2e466e ca4556cb e1d2de1b 71ec478b 53cbb470 | bdc67501 0bd35912 6abad7a2 01dcf577 ac6e6513 |
| 32 | 62ea3d59 6a2e466e f29155b2 e1d2de1b 71ec478b | 34cc8cb2 bdc67501 82f4d644 6abad7a2 01dcf577 |
| 33 | b77bac25 62ea3d59 9a8b919b f29155b2 e1d2de1b | 5fd0f245 34cc8cb2 6f719d40 82f4d644 6abad7a2 |
| 34 | 4b1347e2 b77bac25 58ba8f56 9a8b919b f29155b2 | acfcd3a4 5fd0f245 8d33232c 6f719d40 82f4d644 |
| 35 | 391ef0c4 4b1347e2 6ddeeb09 58ba8f56 9a8b919b | 4efbc2a3 acfcd3a4 57f43c91 8d33232c 6f719d40 |
+----+----------------------------------------------+----------------------------------------------+
| 36 | abbab988 391ef0c4 92c4d1f8 6ddeeb09 58ba8f56 | 33ffb163 4efbc2a3 2b3f34e9 57f43c91 8d33232c |
| 37 | 04f07669 abbab988 0e47bc31 92c4d1f8 6ddeeb09 | ae342e0e 33ffb163 d3bef0a8 2b3f34e9 57f43c91 |
| 38 | b201788b 04f07669 2aeeae62 0e47bc31 92c4d1f8 | 58d2df29 ae342e0e ccffec58 d3bef0a8 2b3f34e9 |
| 39 | 62273351 b201788b 413c1d9a 2aeeae62 0e47bc31 | 65ea40b3 58d2df29 ab8d0b83 ccffec58 d3bef0a8 |
| 40 | 9bdbdd71 62273351 ec805e22 413c1d9a 2aeeae62 | 3f812ba7 65ea40b3 5634b7ca ab8d0b83 ccffec58 |
+----+----------------------------------------------+----------------------------------------------+
| 41 | 95aa398b 9bdbdd71 5889ccd4 ec805e22 413c1d9a | b3ee299e 3f812ba7 d97a902c 5634b7ca ab8d0b83 |
| 42 | 5e28e858 95aa398b 66f6f75c 5889ccd4 ec805e22 | 179eafe3 b3ee299e cfe04ae9 d97a902c 5634b7ca |
| 43 | 95642485 5e28e858 e56a8e62 66f6f75c 5889ccd4 | b51119b4 179eafe3 acfb8a67 cfe04ae9 d97a902c |
| 44 | fa950aba 95642485 178a3a16 e56a8e62 66f6f75c | 9ab60e81 b51119b4 c5e7abf8 acfb8a67 cfe04ae9 |
| 45 | de1e3a01 fa950aba 65590921 178a3a16 e56a8e62 | 5bb1c7ec 9ab60e81 2d44466d c5e7abf8 acfb8a67 |
+----+----------------------------------------------+----------------------------------------------+
| 46 | afe695ab de1e3a01 bea542ae 65590921 178a3a16 | 403653b7 5bb1c7ec 66ad83a0 2d44466d c5e7abf8 |
| 47 | a195ba90 afe695ab 77878e80 bea542ae 65590921 | cb77afa8 403653b7 16ec71fb 66ad83a0 2d44466d |
| 48 | e6d39f43 a195ba90 ebf9a56a 77878e80 bea542ae | 7202d415 cb77afa8 d00d94ed 16ec71fb 66ad83a0 |
| 49 | 0bca9922 e6d39f43 28656ea4 ebf9a56a 77878e80 | 08941513 7202d415 32ddebea d00d94ed 16ec71fb |
| 50 | 6ae826ff 0bca9922 f9b4e7d0 28656ea4 ebf9a56a | 2aa0a625 08941513 5c80b505 32ddebea d00d94ed |
+----+----------------------------------------------+----------------------------------------------+
| 51 | 01ff3253 6ae826ff 82f2a648 f9b4e7d0 28656ea4 | cbd34b71 2aa0a625 c2250544 5c80b505 32ddebea |
| 52 | e2581ce0 01ff3253 daba09bf 82f2a648 f9b4e7d0 | 8703e404 cbd34b71 4aa82989 c2250544 5c80b505 |
| 53 | 56ce73ab e2581ce0 c07fcc94 daba09bf 82f2a648 | 96ca83b2 8703e404 72f4d2dc 4aa82989 c2250544 |
| 54 | ae56e542 56ce73ab 38960738 c07fcc94 daba09bf | 6d3218fe 96ca83b2 21c0f901 72f4d2dc 4aa82989 |
| 55 | 8590c0e8 ae56e542 d5b39cea 38960738 c07fcc94 | b2d219c2 6d3218fe a5b2a0ec 21c0f901 72f4d2dc |
+----+----------------------------------------------+----------------------------------------------+
| 56 | be4a4bea 8590c0e8 ab95b950 d5b39cea 38960738 | 822680fa b2d219c2 9b4c863f a5b2a0ec 21c0f901 |
| 57 | 168ce0bb be4a4bea 2164303a ab95b950 d5b39cea | a985be1b 822680fa acb48670 9b4c863f a5b2a0ec |
| 58 | e1afab22 168ce0bb af9292fa 2164303a ab95b950 | efab27b7 a985be1b a089a03e acb48670 9b4c863f |
| 59 | 982bcbca e1afab22 c5a3382e af9292fa 2164303a | c8936852 efab27b7 ea616f86 a089a03e acb48670 |
| 60 | 9b9d2913 982bcbca b86beac8 c5a3382e af9292fa | 38eef55b c8936852 fbeac9ed ea616f86 a089a03e |
+----+----------------------------------------------+----------------------------------------------+
| 61 | d37db937 9b9d2913 a60af2f2 b86beac8 c5a3382e | 620ca3b4 38eef55b b224da14 fbeac9ed ea616f86 |
| 62 | 85b9d227 d37db937 e6e74a44 a60af2f2 b86beac8 | 67f98e8a 620ca3b4 ce3bbd56 b224da14 fbeac9ed |
| 63 | cd98fbb7 85b9d227 f4df6e4d e6e74a44 a60af2f2 | e39bca05 67f98e8a 188328ed ce3bbd56 b224da14 |
| 64 | bb0f226f cd98fbb7 e16e7489 f4df6e4d e6e74a44 | a14277d7 e39bca05 99fe63a2 188328ed ce3bbd56 |
| 65 | eb59446c bb0f226f f3663eed e16e7489 f4df6e4d | 24dce36a a14277d7 78e6f281 99fe63a2 188328ed |
+----+----------------------------------------------+----------------------------------------------+
| 66 | d37225cb eb59446c eec3c89b f3663eed e16e7489 | bedd3efb 24dce36a e8509df5 78e6f281 99fe63a2 |
| 67 | 111341f3 d37225cb 3ad6511b eec3c89b f3663eed | f513910d bedd3efb 893738da e8509df5 78e6f281 |
| 68 | e79afbf0 111341f3 f4dc8972 3ad6511b eec3c89b | c776f1e9 f513910d efb74fbe 893738da e8509df5 |
| 69 | 8ba00627 e79afbf0 c444d07c f4dc8972 3ad6511b | 3589836c c776f1e9 7d44e443 efb74fbe 893738da |
| 70 | 503c7ae0 8ba00627 39e6befc c444d07c f4dc8972 | 5a4fc24a 3589836c 71ddbc7a 7d44e443 efb74fbe |
+----+----------------------------------------------+----------------------------------------------+
| 71 | 3cd517f9 503c7ae0 e2e80189 39e6befc c444d07c | 412b3634 5a4fc24a 0d6260db 71ddbc7a 7d44e443 |
| 72 | b47ddf0e 3cd517f9 140f1eb8 e2e80189 39e6befc | 94868b8c 412b3634 9693f092 0d6260db 71ddbc7a |
| 73 | 5e3a0780 b47ddf0e 4f3545fe 140f1eb8 e2e80189 | aa88a65f 94868b8c 104acd8d 9693f092 0d6260db |
| 74 | 63db37b2 5e3a0780 ad1f77c3 4f3545fe 140f1eb8 | 4339a539 aa88a65f 2521a2e3 104acd8d 9693f092 |
| 75 | 15e98d17 63db37b2 178e81e0 ad1f77c3 4f3545fe | 688fa2c1 4339a539 eaa22997 2521a2e3 104acd8d |
+----+----------------------------------------------+----------------------------------------------+
| 76 | b0149467 15e98d17 98f6cdec 178e81e0 ad1f77c3 | 798435dd 688fa2c1 50ce694e eaa22997 2521a2e3 |
| 77 | 14b7106a b0149467 c57a6345 98f6cdec 178e81e0 | 0377c280 798435dd 5a23e8b0 50ce694e eaa22997 |
| 78 | 666b8bc6 14b7106a ec052519 c57a6345 98f6cdec | 9766ef90 0377c280 5e610d77 5a23e8b0 50ce694e |
| 79 | 6e9d9f84 666b8bc6 852dc41a ec052519 c57a6345 | 1985047d 9766ef90 00ddf0a0 5e610d77 5a23e8b0 |
| 80 | 72f480ed 6e9d9f84 999ae2f1 852dc41a ec052519 | 3f01cc70 1985047d 25d9bbe4 00ddf0a0 5e610d77 |
+----+----------------------------------------------+----------------------------------------------+
| 81 | da39a3ee 5e6b4b0d 3255bfef 95601890 afd80709 | a646ef71 0952b006 be9498e2 11104516 2233ef67 |
+----+----------------------------------------------+----------------------------------------------+
The first 16 rounds seems to be weaker than usual, but I didn't find practical collisions or preimages for the bugged version yet. I will try to write some code, to analyze it further. For some other non-standard SHA-1 versions, some changes were known to produce collisions, for example when k-values were changed to some "random" ones, then it was exploitable only by the creator: https://malicioussha1.github.io/

Edit: Yes, comparing two different messages for a bugged version can reveal some patterns: the first 16 rounds are very weak. Practically, the message leaves the hash unaffected. Which means this bug reduces the non-standard SHA-1 by 15 rounds, turning it in practice from 80-round hash function into 65-round one. Here is why:
Code:
     +----------------------------------------------+----------------------------------------------+
     | bugged SHA-1 for empty message               | bugged SHA-1 for "abc"                       |
+----+----------------------------------------------+----------------------------------------------+
| 00 | 67452301 efcdab89 98badcfe 10325476 c3d2e1f0 | 67452301 efcdab89 98badcfe 10325476 c3d2e1f0 |
+----+----------------------------------------------+----------------------------------------------+
| 01 | c3d2e270 67452301 7bf36ae2 98badcfe 10325476 | 44364451 67452301 7bf36ae2 98badcfe 10325476 |
| 02 | 10325476 c3d2e270 59d148c0 7bf36ae2 98badcfe | 10325476 44364451 59d148c0 7bf36ae2 98badcfe |
| 03 | 98badcfe 10325476 30f4b89c 59d148c0 7bf36ae2 | 98badcfe 10325476 510d9114 59d148c0 7bf36ae2 |
| 04 | 7bf36ae2 98badcfe 840c951d 30f4b89c 59d148c0 | 7bf36ae2 98badcfe 840c951d 510d9114 59d148c0 |
| 05 | 59d148c0 7bf36ae2 a62eb73f 840c951d 30f4b89c | 59d148c0 7bf36ae2 a62eb73f 840c951d 510d9114 |
+----+----------------------------------------------+----------------------------------------------+
| 06 | 30f4b89c 59d148c0 9efcdab8 a62eb73f 840c951d | 510d9114 59d148c0 9efcdab8 a62eb73f 840c951d |
| 07 | 840c951d 30f4b89c 16745230 9efcdab8 a62eb73f | 840c951d 510d9114 16745230 9efcdab8 a62eb73f |
| 08 | a62eb73f 840c951d 0c3d2e27 16745230 9efcdab8 | a62eb73f 840c951d 14436445 16745230 9efcdab8 |
| 09 | 9efcdab8 a62eb73f 61032547 0c3d2e27 16745230 | 9efcdab8 a62eb73f 61032547 14436445 16745230 |
| 10 | 16745230 9efcdab8 e98badcf 61032547 0c3d2e27 | 16745230 9efcdab8 e98badcf 61032547 14436445 |
+----+----------------------------------------------+----------------------------------------------+
| 11 | 0c3d2e27 16745230 27bf36ae e98badcf 61032547 | 14436445 16745230 27bf36ae e98badcf 61032547 |
| 12 | 61032547 0c3d2e27 059d148c 27bf36ae e98badcf | 61032547 14436445 059d148c 27bf36ae e98badcf |
| 13 | e98badcf 61032547 c30f4b89 059d148c 27bf36ae | e98badcf 61032547 4510d911 059d148c 27bf36ae |
| 14 | 27bf36ae e98badcf d840c951 c30f4b89 059d148c | 27bf36ae e98badcf d840c951 4510d911 059d148c |
| 15 | 059d148c 27bf36ae fa62eb73 d840c951 c30f4b89 | 059d148c 27bf36ae fa62eb73 d840c951 4510d911 |
+----+----------------------------------------------+----------------------------------------------+
| 16 | c30f4b89 059d148c 89efcdab fa62eb73 d840c951 | 5d10d911 059d148c 89efcdab fa62eb73 d840c951 |
| 17 | 909ca51d c30f4b89 01674523 89efcdab fa62eb73 | d19519d3 5d10d911 01674523 89efcdab fa62eb73 |
| 18 | 7261cde1 909ca51d 70c3d2e2 01674523 89efcdab | 0977e531 d19519d3 57443644 01674523 89efcdab |
| 19 | 428fc394 7261cde1 64272947 70c3d2e2 01674523 | 94d541c5 0977e531 f4654674 57443644 01674523 |
| 20 | 0e854e87 428fc394 5c987378 64272947 70c3d2e2 | 4e84d768 94d541c5 425df94c f4654674 57443644 |
+----+----------------------------------------------+----------------------------------------------+
| 21 | 2a78290f 0e854e87 10a3f0e5 5c987378 64272947 | b9a70deb 4e84d768 65355071 425df94c f4654674 |
| 22 | 64c503e7 2a78290f c3a153a1 10a3f0e5 5c987378 | 620d6de1 b9a70deb 13a135da 65355071 425df94c |
| 23 | 5d8d6a50 64c503e7 ca9e0a43 c3a153a1 10a3f0e5 | c5341c65 620d6de1 ee69c37a 13a135da 65355071 |
| 24 | 9f258096 5d8d6a50 d93140f9 ca9e0a43 c3a153a1 | 4a58640b c5341c65 58835b78 ee69c37a 13a135da |
| 25 | 654d74ff 9f258096 17635a94 d93140f9 ca9e0a43 | 02f3b0d1 4a58640b 714d0719 58835b78 ee69c37a |
+----+----------------------------------------------+----------------------------------------------+
| 26 | 349e38cb 654d74ff a7c96025 17635a94 d93140f9 | 258627bd 02f3b0d1 d2961902 714d0719 58835b78 |
| 27 | b1b9944e 349e38cb d9535d3f a7c96025 17635a94 | 194aed87 258627bd 40bcec34 d2961902 714d0719 |
| 28 | 0773d5dc b1b9944e cd278e32 d9535d3f a7c96025 | 41317629 194aed87 496189ef 40bcec34 d2961902 |
| 29 | aaeb5e89 0773d5dc ac6e6513 cd278e32 d9535d3f | 84a29e57 41317629 c652bb61 496189ef 40bcec34 |
| 30 | 0bd35912 aaeb5e89 01dcf577 ac6e6513 cd278e32 | 01ece76c 84a29e57 504c5d8a c652bb61 496189ef |
+----+----------------------------------------------+----------------------------------------------+
| 31 | bdc67501 0bd35912 6abad7a2 01dcf577 ac6e6513 | 10508b69 01ece76c e128a795 504c5d8a c652bb61 |
| 32 | 34cc8cb2 bdc67501 82f4d644 6abad7a2 01dcf577 | 389ec9f7 10508b69 007b39db e128a795 504c5d8a |
| 33 | 5fd0f245 34cc8cb2 6f719d40 82f4d644 6abad7a2 | c69937c3 389ec9f7 441422da 007b39db e128a795 |
| 34 | acfcd3a4 5fd0f245 8d33232c 6f719d40 82f4d644 | a01b5eaa c69937c3 ce27b27d 441422da 007b39db |
| 35 | 4efbc2a3 acfcd3a4 57f43c91 8d33232c 6f719d40 | b11cd2f4 a01b5eaa f1a64df0 ce27b27d 441422da |
+----+----------------------------------------------+----------------------------------------------+
| 36 | 33ffb163 4efbc2a3 2b3f34e9 57f43c91 8d33232c | 3c593453 b11cd2f4 a806d7aa f1a64df0 ce27b27d |
| 37 | ae342e0e 33ffb163 d3bef0a8 2b3f34e9 57f43c91 | cfd32fa7 3c593453 2c4734bd a806d7aa f1a64df0 |
| 38 | 58d2df29 ae342e0e ccffec58 d3bef0a8 2b3f34e9 | b661674e cfd32fa7 cf164d14 2c4734bd a806d7aa |
| 39 | 65ea40b3 58d2df29 ab8d0b83 ccffec58 d3bef0a8 | 15c62947 b661674e f3f4cbe9 cf164d14 2c4734bd |
| 40 | 3f812ba7 65ea40b3 5634b7ca ab8d0b83 ccffec58 | 9e6a2b0b 15c62947 ad9859d3 f3f4cbe9 cf164d14 |
+----+----------------------------------------------+----------------------------------------------+
| 41 | b3ee299e 3f812ba7 d97a902c 5634b7ca ab8d0b83 | a23e9a3e 9e6a2b0b c5718a51 ad9859d3 f3f4cbe9 |
| 42 | 179eafe3 b3ee299e cfe04ae9 d97a902c 5634b7ca | 585bdbfb a23e9a3e e79a8ac2 c5718a51 ad9859d3 |
| 43 | b51119b4 179eafe3 acfb8a67 cfe04ae9 d97a902c | ab251a3c 585bdbfb a88fa68f e79a8ac2 c5718a51 |
| 44 | 9ab60e81 b51119b4 c5e7abf8 acfb8a67 cfe04ae9 | 8f559f91 ab251a3c d616f6fe a88fa68f e79a8ac2 |
| 45 | 5bb1c7ec 9ab60e81 2d44466d c5e7abf8 acfb8a67 | 35e4ac39 8f559f91 2ac9468f d616f6fe a88fa68f |
+----+----------------------------------------------+----------------------------------------------+
| 46 | 403653b7 5bb1c7ec 66ad83a0 2d44466d c5e7abf8 | 4296c190 35e4ac39 63d567e4 2ac9468f d616f6fe |
| 47 | cb77afa8 403653b7 16ec71fb 66ad83a0 2d44466d | b8f576a6 4296c190 4d792b0e 63d567e4 2ac9468f |
| 48 | 7202d415 cb77afa8 d00d94ed 16ec71fb 66ad83a0 | 61bd836b b8f576a6 10a5b064 4d792b0e 63d567e4 |
| 49 | 08941513 7202d415 32ddebea d00d94ed 16ec71fb | 2b4162b7 61bd836b ae3d5da9 10a5b064 4d792b0e |
| 50 | 2aa0a625 08941513 5c80b505 32ddebea d00d94ed | 9ba4e842 2b4162b7 d86f60da ae3d5da9 10a5b064 |
+----+----------------------------------------------+----------------------------------------------+
| 51 | cbd34b71 2aa0a625 c2250544 5c80b505 32ddebea | 622e37d1 9ba4e842 cad058ad d86f60da ae3d5da9 |
| 52 | 8703e404 cbd34b71 4aa82989 c2250544 5c80b505 | 3cf33d6f 622e37d1 a6e93a10 cad058ad d86f60da |
| 53 | 96ca83b2 8703e404 72f4d2dc 4aa82989 c2250544 | f1f37dc2 3cf33d6f 588b8df4 a6e93a10 cad058ad |
| 54 | 6d3218fe 96ca83b2 21c0f901 72f4d2dc 4aa82989 | d5470c51 f1f37dc2 cf3ccf5b 588b8df4 a6e93a10 |
| 55 | b2d219c2 6d3218fe a5b2a0ec 21c0f901 72f4d2dc | 42c0fcbf d5470c51 bc7cdf70 cf3ccf5b 588b8df4 |
+----+----------------------------------------------+----------------------------------------------+
| 56 | 822680fa b2d219c2 9b4c863f a5b2a0ec 21c0f901 | 35dc1256 42c0fcbf 7551c314 bc7cdf70 cf3ccf5b |
| 57 | a985be1b 822680fa acb48670 9b4c863f a5b2a0ec | 47f0bae7 35dc1256 d0b03f2f 7551c314 bc7cdf70 |
| 58 | efab27b7 a985be1b a089a03e acb48670 9b4c863f | 62e273d6 47f0bae7 8d770495 d0b03f2f 7551c314 |
| 59 | c8936852 efab27b7 ea616f86 a089a03e acb48670 | fb10c0c8 62e273d6 d1fc2eb9 8d770495 d0b03f2f |
| 60 | 38eef55b c8936852 fbeac9ed ea616f86 a089a03e | 191eb60b fb10c0c8 98b89cf5 d1fc2eb9 8d770495 |
+----+----------------------------------------------+----------------------------------------------+
| 61 | 620ca3b4 38eef55b b224da14 fbeac9ed ea616f86 | e85ffd98 191eb60b 3ec43032 98b89cf5 d1fc2eb9 |
| 62 | 67f98e8a 620ca3b4 ce3bbd56 b224da14 fbeac9ed | 0a223f24 e85ffd98 c647ad82 3ec43032 98b89cf5 |
| 63 | e39bca05 67f98e8a 188328ed ce3bbd56 b224da14 | 03ea6b66 0a223f24 3a17ff66 c647ad82 3ec43032 |
| 64 | a14277d7 e39bca05 99fe63a2 188328ed ce3bbd56 | 204945d1 03ea6b66 02888fc9 3a17ff66 c647ad82 |
| 65 | 24dce36a a14277d7 78e6f281 99fe63a2 188328ed | 94213d3d 204945d1 80fa9ad9 02888fc9 3a17ff66 |
+----+----------------------------------------------+----------------------------------------------+
| 66 | bedd3efb 24dce36a e8509df5 78e6f281 99fe63a2 | 2addc8af 94213d3d 48125174 80fa9ad9 02888fc9 |
| 67 | f513910d bedd3efb 893738da e8509df5 78e6f281 | 40682e8b 2addc8af 65084f4f 48125174 80fa9ad9 |
| 68 | c776f1e9 f513910d efb74fbe 893738da e8509df5 | 4b0f6a18 40682e8b cab7722b 65084f4f 48125174 |
| 69 | 3589836c c776f1e9 7d44e443 efb74fbe 893738da | d6f5166c 4b0f6a18 d01a0ba2 cab7722b 65084f4f |
| 70 | 5a4fc24a 3589836c 71ddbc7a 7d44e443 efb74fbe | 5fb05310 d6f5166c 12c3da86 d01a0ba2 cab7722b |
+----+----------------------------------------------+----------------------------------------------+
| 71 | 412b3634 5a4fc24a 0d6260db 71ddbc7a 7d44e443 | c47b7531 5fb05310 35bd459b 12c3da86 d01a0ba2 |
| 72 | 94868b8c 412b3634 9693f092 0d6260db 71ddbc7a | 7701e501 c47b7531 17ec14c4 35bd459b 12c3da86 |
| 73 | aa88a65f 94868b8c 104acd8d 9693f092 0d6260db | 4a7f8acf 7701e501 711edd4c 17ec14c4 35bd459b |
| 74 | 4339a539 aa88a65f 2521a2e3 104acd8d 9693f092 | 881c981d 4a7f8acf 5dc07940 711edd4c 17ec14c4 |
| 75 | 688fa2c1 4339a539 eaa22997 2521a2e3 104acd8d | 4d86eb2e 881c981d d29fe2b3 5dc07940 711edd4c |
+----+----------------------------------------------+----------------------------------------------+
| 76 | 798435dd 688fa2c1 50ce694e eaa22997 2521a2e3 | ea09758d 4d86eb2e 62072607 d29fe2b3 5dc07940 |
| 77 | 0377c280 798435dd 5a23e8b0 50ce694e eaa22997 | b114e1b6 ea09758d 9361bacb 62072607 d29fe2b3 |
| 78 | 9766ef90 0377c280 5e610d77 5a23e8b0 50ce694e | db0fbaaa b114e1b6 7a825d63 9361bacb 62072607 |
| 79 | 1985047d 9766ef90 00ddf0a0 5e610d77 5a23e8b0 | 33d6da1c db0fbaaa ac45386d 7a825d63 9361bacb |
| 80 | 3f01cc70 1985047d 25d9bbe4 00ddf0a0 5e610d77 | 616acc53 33d6da1c b6c3eeaa ac45386d 7a825d63 |
+----+----------------------------------------------+----------------------------------------------+
| 81 | a646ef71 0952b006 be9498e2 11104516 2233ef67 | c8afef54 23a485a5 4f7ecba8 bc778ce3 3e553f53 |
+----+----------------------------------------------+----------------------------------------------+
As we can see, the 16th round for both cases is very similar:
Code:
buggy(16,""   )=c30f4b89059d148c89efcdabfa62eb73d840c951
buggy(16,"abc")=5d10d911059d148c89efcdabfa62eb73d840c951
Which means, instead of 2^160 combinations, there are only 2^32 possible values for the 16th round, and it can be directly controlled, by changing the first four bytes of the message.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!