threads / discuss / 64861

The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa

Subject: The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa

## tl;dr

10 messages between Jan 23, 2026 and Jan 25, 2026.

replies: 9people: 4as markdown or json

Klaus Sembritzki· Jan 23, 2026, 20:16 UTC · lore
Dear all,
see for yourself:

$ # xy: 1337 $ echo xy | sha256sum $ 3b2fc206fd92be3e70843a6d6d466b1f400383418b3c16f2f0af89981f1337f3

$ # za: acbad $ echo za | sha256sum $ 28832ea947ea9588ff3acbad546b27fd001a875215beccf0e5e4eee51cc81a2e

$ # My initials (ks): 1aa $ echo ks | sha256sum $ 1aa44e718d5bc9b7ff2003dbbb6f154e16636d5c2128ffce4751af5124b65337

$ # 50566750337 $ echo thinking | sha256sum $ 50566750337beb9e98e553fd9196d10576f9eb0cbc6b66e2586b9d73af4f352f

Less strange results, but I still wonder if this is random, as expected after reading this: https://crypto.stackexchange.com/a/12840

$ # It was bad AF BC: $ # bc, badfaf $ echo bc | sha256sum $ bc18cd878fc136926875bcb4bddc7f3badfaf4298f5dd1a9fd4c1b9692b624fc

$ # 439247560, 1532557 $ echo vw | sha256sum $ 439247560f158e6c80ea9b43c3345b4468ccf6fb1532557b1bab8908ad8b075a

I do not need my name attached to these examples, even though I am 1aa.

Cheers, Klaus Sembritzki

Jeff King· Jan 23, 2026, 21:06 UTC · re: Klaus Sembritzki · lore

Re: The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa

On Fri, Jan 23, 2026 at 09:16:46PM +0100, Klaus Sembritzki wrote:
Show 7 quoted lines
> $ # My initials (ks): 1aa
> $ echo ks | sha256sum
> $ 1aa44e718d5bc9b7ff2003dbbb6f154e16636d5c2128ffce4751af5124b65337
> 
> $ # 50566750337
> $ echo thinking | sha256sum
> $ 50566750337beb9e98e553fd9196d10576f9eb0cbc6b66e2586b9d73af4f352f
Oh man, I've got deadbeef!
  $ echo jk35252822 | sha256sum
  33f1a74529870456c56ad97c59cfed6bdeadbeef9b9bc3f4ff49bb203e36f96b
What could it all mean?
-Peff
Marc Branchaud· Jan 23, 2026, 21:57 UTC · re: Jeff King · lore

Re: The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa

Deep Crypto is obviously far more insidious than anyone expected. How could we have not realized that our SHA IDs were so subversive?

I mean, ab6edf73?  Really?  Who ever thought that was even remotely OK?

We need to immediately replace our SHA IDs with sequences of semantically-neutral symbols. I suggest we use non-hex integers to represent the value of each byte (hexadecimal letters being the work of the devil -- I mean, "hex" is right there in the name!), and use something neutral like □ (U25A1) as a separator (but only by default; this symbol must be configurable). For example:

	12deadbeef45 --> 12□222□173□190□239□45

(I realize that numbers themselves can carry deeply harmful baggage, but I'm hoping the integers from 1 to 255 aren't too offensive. OK, maybe tolerating 111 is asking too much...)

I only hope we can spare future generations from our modern deprivations.
		M.
On 2026-01-23 14:06, Jeff King wrote:
Show 19 quoted lines
> On Fri, Jan 23, 2026 at 09:16:46PM +0100, Klaus Sembritzki wrote:
> 
>> $ # My initials (ks): 1aa
>> $ echo ks | sha256sum
>> $ 1aa44e718d5bc9b7ff2003dbbb6f154e16636d5c2128ffce4751af5124b65337
>>
>> $ # 50566750337
>> $ echo thinking | sha256sum
>> $ 50566750337beb9e98e553fd9196d10576f9eb0cbc6b66e2586b9d73af4f352f
> 
> Oh man, I've got deadbeef!
> 
>    $ echo jk35252822 | sha256sum
>    33f1a74529870456c56ad97c59cfed6bdeadbeef9b9bc3f4ff49bb203e36f96b
> 
> What could it all mean?
> 
> -Peff
> 
Junio C Hamano· Jan 23, 2026, 22:36 UTC · re: Jeff King · lore

Re: The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa

Jeff King <peff@peff.net> writes:
Show 16 quoted lines
> On Fri, Jan 23, 2026 at 09:16:46PM +0100, Klaus Sembritzki wrote:
>
>> $ # My initials (ks): 1aa
>> $ echo ks | sha256sum
>> $ 1aa44e718d5bc9b7ff2003dbbb6f154e16636d5c2128ffce4751af5124b65337
>> 
>> $ # 50566750337
>> $ echo thinking | sha256sum
>> $ 50566750337beb9e98e553fd9196d10576f9eb0cbc6b66e2586b9d73af4f352f
>
> Oh man, I've got deadbeef!
>
>   $ echo jk35252822 | sha256sum
>   33f1a74529870456c56ad97c59cfed6bdeadbeef9b9bc3f4ff49bb203e36f96b
>
> What could it all mean?

Sorry, but I have to admit that I completely lack humor receptor cells.

Klaus Sembritzki· Jan 23, 2026, 23:30 UTC · re: Junio C Hamano · lore

Re: The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa

1. The brute-forced hash
>  Sorry, but I have to admit that I completely lack humor receptor

That is a pity, because the brute-forced hash contains "codoodikk", which reads as "code-dude and dikk".

33f1a74529870456c56ad97c59cfed6bdeadbeef9b9bc3f4ff49bb203e36f96b cco1jgdebihg0deflefjmigleilonmfkmnjmknnoikiklcodoodikkb0cncfoifk

2. Jeff King's real hash

echo jk | sha256sum 720daff2aefd2b3457cbd597509b0fa399e258444302c2851f8d3cdd8ad781eb 720 = 2*360 = 0

3. Junio C Hamano's real hash

echo jch | sha256sum c666df2af21b29a6b2c7f3b9deddda805f2ed8dcd3c72a6fbf38f6c729e2c98a 666

On Fri, Jan 23, 2026 at 11:36 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 25 quoted lines
>
> Jeff King <peff@peff.net> writes:
>
> > On Fri, Jan 23, 2026 at 09:16:46PM +0100, Klaus Sembritzki wrote:
> >
> >> $ # My initials (ks): 1aa
> >> $ echo ks | sha256sum
> >> $ 1aa44e718d5bc9b7ff2003dbbb6f154e16636d5c2128ffce4751af5124b65337
> >>
> >> $ # 50566750337
> >> $ echo thinking | sha256sum
> >> $ 50566750337beb9e98e553fd9196d10576f9eb0cbc6b66e2586b9d73af4f352f
> >
> > Oh man, I've got deadbeef!
> >
> >   $ echo jk35252822 | sha256sum
> >   33f1a74529870456c56ad97c59cfed6bdeadbeef9b9bc3f4ff49bb203e36f96b
> >
> > What could it all mean?
>
> Sorry, but I have to admit that I completely lack humor receptor
> cells.
>
>
>
Jeff King· Jan 24, 2026, 07:28 UTC · re: Junio C Hamano · lore

Re: The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa

On Fri, Jan 23, 2026 at 02:36:41PM -0800, Junio C Hamano wrote:
Show 21 quoted lines
> Jeff King <peff@peff.net> writes:
> 
> > On Fri, Jan 23, 2026 at 09:16:46PM +0100, Klaus Sembritzki wrote:
> >
> >> $ # My initials (ks): 1aa
> >> $ echo ks | sha256sum
> >> $ 1aa44e718d5bc9b7ff2003dbbb6f154e16636d5c2128ffce4751af5124b65337
> >> 
> >> $ # 50566750337
> >> $ echo thinking | sha256sum
> >> $ 50566750337beb9e98e553fd9196d10576f9eb0cbc6b66e2586b9d73af4f352f
> >
> > Oh man, I've got deadbeef!
> >
> >   $ echo jk35252822 | sha256sum
> >   33f1a74529870456c56ad97c59cfed6bdeadbeef9b9bc3f4ff49bb203e36f96b
> >
> > What could it all mean?
> 
> Sorry, but I have to admit that I completely lack humor receptor
> cells.
Probably because it was not that funny. :)

The original message seemed to be looking for Numerology-style meanings in random data. I wasn't sure if it was serious or not, but I could not resist either playing along (if not) or trolling (if so).

But here's my deadbeef brute-force program for fun.
-Peff

-- >8 -- #include <stdio.h> #include <string.h> #include <openssl/evp.h>

int main(int argc, const char **argv)
{
	const char needle[] = { 0xde, 0xad, 0xbe, 0xef };
	const EVP_MD *algo = EVP_sha256();
	EVP_MD_CTX *ctx = EVP_MD_CTX_new();
	EVP_DigestInit_ex(ctx, algo, NULL);
	while (*++argv)
		EVP_DigestUpdate(ctx, *argv, strlen(*argv));
	for (unsigned i = 0; ; i++) {
		char buf[16];
		char *p;
		unsigned char digest[32];
		EVP_MD_CTX *copy = EVP_MD_CTX_dup(ctx);
		p = buf + sizeof(buf);
		for (unsigned v = i; v; v /= 10)
			*--p = '0' + (v % 10);
		EVP_DigestUpdate(copy, p, buf + sizeof(buf) - p);
		EVP_DigestUpdate(copy, "\n", 1);
		EVP_DigestFinal_ex(copy, digest, NULL);
		EVP_MD_CTX_free(copy);
		if (memmem(digest, sizeof(digest), needle, sizeof(needle)))
			printf("%d\n", i);
	}
}
Klaus Sembritzki· Jan 24, 2026, 09:25 UTC · re: Jeff King · lore

Re: The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa

On Sat, Jan 24, 2026 at 8:28 AM Jeff King <peff@peff.net> wrote:
Show 67 quoted lines
>
> On Fri, Jan 23, 2026 at 02:36:41PM -0800, Junio C Hamano wrote:
>
> > Jeff King <peff@peff.net> writes:
> >
> > > On Fri, Jan 23, 2026 at 09:16:46PM +0100, Klaus Sembritzki wrote:
> > >
> > >> $ # My initials (ks): 1aa
> > >> $ echo ks | sha256sum
> > >> $ 1aa44e718d5bc9b7ff2003dbbb6f154e16636d5c2128ffce4751af5124b65337
> > >>
> > >> $ # 50566750337
> > >> $ echo thinking | sha256sum
> > >> $ 50566750337beb9e98e553fd9196d10576f9eb0cbc6b66e2586b9d73af4f352f
> > >
> > > Oh man, I've got deadbeef!
> > >
> > >   $ echo jk35252822 | sha256sum
> > >   33f1a74529870456c56ad97c59cfed6bdeadbeef9b9bc3f4ff49bb203e36f96b
> > >
> > > What could it all mean?
> >
> > Sorry, but I have to admit that I completely lack humor receptor
> > cells.
>
> Probably because it was not that funny. :)
>
> The original message seemed to be looking for Numerology-style meanings
> in random data. I wasn't sure if it was serious or not, but I could not
> resist either playing along (if not) or trolling (if so).
>
> But here's my deadbeef brute-force program for fun.
>
> -Peff
>
> -- >8 --
> #include <stdio.h>
> #include <string.h>
> #include <openssl/evp.h>
>
> int main(int argc, const char **argv)
> {
>         const char needle[] = { 0xde, 0xad, 0xbe, 0xef };
>         const EVP_MD *algo = EVP_sha256();
>         EVP_MD_CTX *ctx = EVP_MD_CTX_new();
>
>         EVP_DigestInit_ex(ctx, algo, NULL);
>         while (*++argv)
>                 EVP_DigestUpdate(ctx, *argv, strlen(*argv));
>
>         for (unsigned i = 0; ; i++) {
>                 char buf[16];
>                 char *p;
>                 unsigned char digest[32];
>                 EVP_MD_CTX *copy = EVP_MD_CTX_dup(ctx);
>
>                 p = buf + sizeof(buf);
>                 for (unsigned v = i; v; v /= 10)
>                         *--p = '0' + (v % 10);
>                 EVP_DigestUpdate(copy, p, buf + sizeof(buf) - p);
>                 EVP_DigestUpdate(copy, "\n", 1);
>                 EVP_DigestFinal_ex(copy, digest, NULL);
>                 EVP_MD_CTX_free(copy);
>                 if (memmem(digest, sizeof(digest), needle, sizeof(needle)))
>                         printf("%d\n", i);
>         }
> }

Incrementing the MSB instead of the LSB (indexing naturally starts with 1 in that case) seems to improve the performance, and it finds different solutions, if the program is terminated early. The rationale is that there is autocorrelation in the observations, though I cannot judge what that means in this concrete example. The speedup is not that dramatic here, so SHA256 seems to be pretty random.

#include <stdio.h> #include <string.h> #include <stdint.h> #include <openssl/evp.h>

#ifdef POLYFILL
EVP_MD_CTX *EVP_MD_CTX_dup(const EVP_MD_CTX *in)
{
    EVP_MD_CTX *out = EVP_MD_CTX_new();
    if (out != NULL && !EVP_MD_CTX_copy_ex(out, in)) {
        EVP_MD_CTX_free(out);
        out = NULL;
    }
    return out;
}
#endif

#define REVERTED_BIT(n, position, width) (((n & (1 << position)) >> position) << (width - position - 2))

uint32_t revert_bits(uint32_t n, uint32_t width) {
    uint32_t result = 0;
    for (uint32_t i = 0; i < width; ++i) {
        result |= REVERTED_BIT(n, i, width);
    }
    return result;
}
int main(int argc, const char **argv)
{
    const char needle[] = { 0xde, 0xad, 0xbe, 0xef };
    const EVP_MD *algo = EVP_sha256();
    EVP_MD_CTX *ctx = EVP_MD_CTX_new();
    EVP_DigestInit_ex(ctx, algo, NULL);
    while (*++argv)
        EVP_DigestUpdate(ctx, *argv, strlen(*argv));
    for (uint32_t n = 1; ; n++) {
#if (COUNTER_WIDTH != 0)
        uint32_t i = revert_bits(n, COUNTER_WIDTH);
#else
        uint32_t i = n;
#endif
        // printf("%u %u\n", n, i);
        char buf[16];
        char *p;
        unsigned char digest[32];
        EVP_MD_CTX *copy = EVP_MD_CTX_dup(ctx);
        p = buf + sizeof(buf);
        for (uint32_t v = i; v; v /= 10)
            *--p = '0' + (v % 10);
        EVP_DigestUpdate(copy, p, buf + sizeof(buf) - p);
        EVP_DigestUpdate(copy, "\n", 1);
        EVP_DigestFinal_ex(copy, digest, NULL);
        EVP_MD_CTX_free(copy);
        if (memmem(digest, sizeof(digest), needle, sizeof(needle)))
        {
            printf("counter width: %2u | n: %10u | i: %10u\n",
COUNTER_WIDTH, n, i);
            return 0;
        }
    }
    return 1;
}

cc -DPOLYFILL -DCOUNTER_WIDTH=32 jk_evp.c -lssl -lcrypto -o jk_evp_msb_32 cc -DPOLYFILL -DCOUNTER_WIDTH=31 jk_evp.c -lssl -lcrypto -o jk_evp_msb_31 cc -DPOLYFILL -DCOUNTER_WIDTH=30 jk_evp.c -lssl -lcrypto -o jk_evp_msb_30 cc -DPOLYFILL -DCOUNTER_WIDTH=29 jk_evp.c -lssl -lcrypto -o jk_evp_msb_29 cc -DPOLYFILL -DCOUNTER_WIDTH=0 jk_evp.c -lssl -lcrypto -o jk_evp_0 counter width: 32 | n: 103832253 | i: 1588397616 counter width: 31 | n: 62413559 | i: 1003915120 counter width: 30 | n: 166340413 | i: 396135154 counter width: 29 | n: 137077701 | i: 171728193 counter width: 0 | n: 171728193 | i: 171728193

Klaus Sembritzki· Jan 25, 2026, 09:47 UTC · re: Klaus Sembritzki · lore

Re: The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa

On Sat, Jan 24, 2026 at 10:25 AM Klaus Sembritzki <klausem@gmail.com> wrote:
Show 156 quoted lines
>
> On Sat, Jan 24, 2026 at 8:28 AM Jeff King <peff@peff.net> wrote:
> >
> > On Fri, Jan 23, 2026 at 02:36:41PM -0800, Junio C Hamano wrote:
> >
> > > Jeff King <peff@peff.net> writes:
> > >
> > > > On Fri, Jan 23, 2026 at 09:16:46PM +0100, Klaus Sembritzki wrote:
> > > >
> > > >> $ # My initials (ks): 1aa
> > > >> $ echo ks | sha256sum
> > > >> $ 1aa44e718d5bc9b7ff2003dbbb6f154e16636d5c2128ffce4751af5124b65337
> > > >>
> > > >> $ # 50566750337
> > > >> $ echo thinking | sha256sum
> > > >> $ 50566750337beb9e98e553fd9196d10576f9eb0cbc6b66e2586b9d73af4f352f
> > > >
> > > > Oh man, I've got deadbeef!
> > > >
> > > >   $ echo jk35252822 | sha256sum
> > > >   33f1a74529870456c56ad97c59cfed6bdeadbeef9b9bc3f4ff49bb203e36f96b
> > > >
> > > > What could it all mean?
> > >
> > > Sorry, but I have to admit that I completely lack humor receptor
> > > cells.
> >
> > Probably because it was not that funny. :)
> >
> > The original message seemed to be looking for Numerology-style meanings
> > in random data. I wasn't sure if it was serious or not, but I could not
> > resist either playing along (if not) or trolling (if so).
> >
> > But here's my deadbeef brute-force program for fun.
> >
> > -Peff
> >
> > -- >8 --
> > #include <stdio.h>
> > #include <string.h>
> > #include <openssl/evp.h>
> >
> > int main(int argc, const char **argv)
> > {
> >         const char needle[] = { 0xde, 0xad, 0xbe, 0xef };
> >         const EVP_MD *algo = EVP_sha256();
> >         EVP_MD_CTX *ctx = EVP_MD_CTX_new();
> >
> >         EVP_DigestInit_ex(ctx, algo, NULL);
> >         while (*++argv)
> >                 EVP_DigestUpdate(ctx, *argv, strlen(*argv));
> >
> >         for (unsigned i = 0; ; i++) {
> >                 char buf[16];
> >                 char *p;
> >                 unsigned char digest[32];
> >                 EVP_MD_CTX *copy = EVP_MD_CTX_dup(ctx);
> >
> >                 p = buf + sizeof(buf);
> >                 for (unsigned v = i; v; v /= 10)
> >                         *--p = '0' + (v % 10);
> >                 EVP_DigestUpdate(copy, p, buf + sizeof(buf) - p);
> >                 EVP_DigestUpdate(copy, "\n", 1);
> >                 EVP_DigestFinal_ex(copy, digest, NULL);
> >                 EVP_MD_CTX_free(copy);
> >                 if (memmem(digest, sizeof(digest), needle, sizeof(needle)))
> >                         printf("%d\n", i);
> >         }
> > }
>
> Incrementing the MSB instead of the LSB (indexing naturally starts
> with 1 in that case) seems to improve the performance, and it finds
> different solutions, if the program is terminated early.
> The rationale is that there is autocorrelation in the observations,
> though I cannot judge what that means in this concrete example. The
> speedup is not that dramatic here, so SHA256 seems to be pretty
> random.
>
> #include <stdio.h>
> #include <string.h>
> #include <stdint.h>
> #include <openssl/evp.h>
>
> #ifdef POLYFILL
> EVP_MD_CTX *EVP_MD_CTX_dup(const EVP_MD_CTX *in)
> {
>     EVP_MD_CTX *out = EVP_MD_CTX_new();
>
>     if (out != NULL && !EVP_MD_CTX_copy_ex(out, in)) {
>         EVP_MD_CTX_free(out);
>         out = NULL;
>     }
>     return out;
> }
> #endif
>
> #define REVERTED_BIT(n, position, width) (((n & (1 << position)) >>
> position) << (width - position - 2))
>
> uint32_t revert_bits(uint32_t n, uint32_t width) {
>     uint32_t result = 0;
>     for (uint32_t i = 0; i < width; ++i) {
>         result |= REVERTED_BIT(n, i, width);
>     }
>     return result;
> }
>
> int main(int argc, const char **argv)
> {
>     const char needle[] = { 0xde, 0xad, 0xbe, 0xef };
>     const EVP_MD *algo = EVP_sha256();
>     EVP_MD_CTX *ctx = EVP_MD_CTX_new();
>
>     EVP_DigestInit_ex(ctx, algo, NULL);
>     while (*++argv)
>         EVP_DigestUpdate(ctx, *argv, strlen(*argv));
>
>     for (uint32_t n = 1; ; n++) {
> #if (COUNTER_WIDTH != 0)
>         uint32_t i = revert_bits(n, COUNTER_WIDTH);
> #else
>         uint32_t i = n;
> #endif
>         // printf("%u %u\n", n, i);
>         char buf[16];
>         char *p;
>         unsigned char digest[32];
>         EVP_MD_CTX *copy = EVP_MD_CTX_dup(ctx);
>
>         p = buf + sizeof(buf);
>         for (uint32_t v = i; v; v /= 10)
>             *--p = '0' + (v % 10);
>         EVP_DigestUpdate(copy, p, buf + sizeof(buf) - p);
>         EVP_DigestUpdate(copy, "\n", 1);
>         EVP_DigestFinal_ex(copy, digest, NULL);
>         EVP_MD_CTX_free(copy);
>         if (memmem(digest, sizeof(digest), needle, sizeof(needle)))
>         {
>             printf("counter width: %2u | n: %10u | i: %10u\n",
> COUNTER_WIDTH, n, i);
>             return 0;
>         }
>     }
>     return 1;
> }
>
> cc -DPOLYFILL -DCOUNTER_WIDTH=32 jk_evp.c -lssl -lcrypto -o jk_evp_msb_32
> cc -DPOLYFILL -DCOUNTER_WIDTH=31 jk_evp.c -lssl -lcrypto -o jk_evp_msb_31
> cc -DPOLYFILL -DCOUNTER_WIDTH=30 jk_evp.c -lssl -lcrypto -o jk_evp_msb_30
> cc -DPOLYFILL -DCOUNTER_WIDTH=29 jk_evp.c -lssl -lcrypto -o jk_evp_msb_29
> cc -DPOLYFILL -DCOUNTER_WIDTH=0 jk_evp.c -lssl -lcrypto -o jk_evp_0
> counter width: 32 | n:  103832253 | i: 1588397616
> counter width: 31 | n:   62413559 | i: 1003915120
> counter width: 30 | n:  166340413 | i:  396135154
> counter width: 29 | n:  137077701 | i:  171728193
> counter width:  0 | n:  171728193 | i:  171728193

I have to admit there is a bug in my previous code, it only works correctly for even numbers. It should have been:

#define REVERTED_BIT(n, position, width) (((n & (1 << position)) >> position) << (width - position - 2 + (width & 1)))

uint32_t revert_bits(uint32_t n, uint32_t width) {
    uint32_t result = 0;
    for (uint32_t i = 0; i < width; ++i) {
        result |= REVERTED_BIT(n, i, width);
    }
    return result;
}

The actual performance measurements are: counter width: 32 | n: 103832253 | i: 1588397616 counter width: 31 | n: 103832253 | i: 1588397616 counter width: 30 | n: 166340413 | i: 396135154 counter width: 29 | n: 166340413 | i: 396135154 counter width: 28 | n: 268041599 | i: 2281045247 # 2**28 is close to the first finding when counting by incrementing the LSB, so this is slow. counter width: 27: This does not find anything, because 2**27 is lower than the first finding when counting by incrementing the LSB. counter width: 0 | n: 171728193 | i: 171728193 # math.log2(171728193) = 27.35555166834193

Klaus Sembritzki· Jan 25, 2026, 11:25 UTC · re: Klaus Sembritzki · lore

Re: The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa

On Sun, Jan 25, 2026 at 10:47 AM Klaus Sembritzki <klausem@gmail.com> wrote:
Show 185 quoted lines
>
> On Sat, Jan 24, 2026 at 10:25 AM Klaus Sembritzki <klausem@gmail.com> wrote:
> >
> > On Sat, Jan 24, 2026 at 8:28 AM Jeff King <peff@peff.net> wrote:
> > >
> > > On Fri, Jan 23, 2026 at 02:36:41PM -0800, Junio C Hamano wrote:
> > >
> > > > Jeff King <peff@peff.net> writes:
> > > >
> > > > > On Fri, Jan 23, 2026 at 09:16:46PM +0100, Klaus Sembritzki wrote:
> > > > >
> > > > >> $ # My initials (ks): 1aa
> > > > >> $ echo ks | sha256sum
> > > > >> $ 1aa44e718d5bc9b7ff2003dbbb6f154e16636d5c2128ffce4751af5124b65337
> > > > >>
> > > > >> $ # 50566750337
> > > > >> $ echo thinking | sha256sum
> > > > >> $ 50566750337beb9e98e553fd9196d10576f9eb0cbc6b66e2586b9d73af4f352f
> > > > >
> > > > > Oh man, I've got deadbeef!
> > > > >
> > > > >   $ echo jk35252822 | sha256sum
> > > > >   33f1a74529870456c56ad97c59cfed6bdeadbeef9b9bc3f4ff49bb203e36f96b
> > > > >
> > > > > What could it all mean?
> > > >
> > > > Sorry, but I have to admit that I completely lack humor receptor
> > > > cells.
> > >
> > > Probably because it was not that funny. :)
> > >
> > > The original message seemed to be looking for Numerology-style meanings
> > > in random data. I wasn't sure if it was serious or not, but I could not
> > > resist either playing along (if not) or trolling (if so).
> > >
> > > But here's my deadbeef brute-force program for fun.
> > >
> > > -Peff
> > >
> > > -- >8 --
> > > #include <stdio.h>
> > > #include <string.h>
> > > #include <openssl/evp.h>
> > >
> > > int main(int argc, const char **argv)
> > > {
> > >         const char needle[] = { 0xde, 0xad, 0xbe, 0xef };
> > >         const EVP_MD *algo = EVP_sha256();
> > >         EVP_MD_CTX *ctx = EVP_MD_CTX_new();
> > >
> > >         EVP_DigestInit_ex(ctx, algo, NULL);
> > >         while (*++argv)
> > >                 EVP_DigestUpdate(ctx, *argv, strlen(*argv));
> > >
> > >         for (unsigned i = 0; ; i++) {
> > >                 char buf[16];
> > >                 char *p;
> > >                 unsigned char digest[32];
> > >                 EVP_MD_CTX *copy = EVP_MD_CTX_dup(ctx);
> > >
> > >                 p = buf + sizeof(buf);
> > >                 for (unsigned v = i; v; v /= 10)
> > >                         *--p = '0' + (v % 10);
> > >                 EVP_DigestUpdate(copy, p, buf + sizeof(buf) - p);
> > >                 EVP_DigestUpdate(copy, "\n", 1);
> > >                 EVP_DigestFinal_ex(copy, digest, NULL);
> > >                 EVP_MD_CTX_free(copy);
> > >                 if (memmem(digest, sizeof(digest), needle, sizeof(needle)))
> > >                         printf("%d\n", i);
> > >         }
> > > }
> >
> > Incrementing the MSB instead of the LSB (indexing naturally starts
> > with 1 in that case) seems to improve the performance, and it finds
> > different solutions, if the program is terminated early.
> > The rationale is that there is autocorrelation in the observations,
> > though I cannot judge what that means in this concrete example. The
> > speedup is not that dramatic here, so SHA256 seems to be pretty
> > random.
> >
> > #include <stdio.h>
> > #include <string.h>
> > #include <stdint.h>
> > #include <openssl/evp.h>
> >
> > #ifdef POLYFILL
> > EVP_MD_CTX *EVP_MD_CTX_dup(const EVP_MD_CTX *in)
> > {
> >     EVP_MD_CTX *out = EVP_MD_CTX_new();
> >
> >     if (out != NULL && !EVP_MD_CTX_copy_ex(out, in)) {
> >         EVP_MD_CTX_free(out);
> >         out = NULL;
> >     }
> >     return out;
> > }
> > #endif
> >
> > #define REVERTED_BIT(n, position, width) (((n & (1 << position)) >>
> > position) << (width - position - 2))
> >
> > uint32_t revert_bits(uint32_t n, uint32_t width) {
> >     uint32_t result = 0;
> >     for (uint32_t i = 0; i < width; ++i) {
> >         result |= REVERTED_BIT(n, i, width);
> >     }
> >     return result;
> > }
> >
> > int main(int argc, const char **argv)
> > {
> >     const char needle[] = { 0xde, 0xad, 0xbe, 0xef };
> >     const EVP_MD *algo = EVP_sha256();
> >     EVP_MD_CTX *ctx = EVP_MD_CTX_new();
> >
> >     EVP_DigestInit_ex(ctx, algo, NULL);
> >     while (*++argv)
> >         EVP_DigestUpdate(ctx, *argv, strlen(*argv));
> >
> >     for (uint32_t n = 1; ; n++) {
> > #if (COUNTER_WIDTH != 0)
> >         uint32_t i = revert_bits(n, COUNTER_WIDTH);
> > #else
> >         uint32_t i = n;
> > #endif
> >         // printf("%u %u\n", n, i);
> >         char buf[16];
> >         char *p;
> >         unsigned char digest[32];
> >         EVP_MD_CTX *copy = EVP_MD_CTX_dup(ctx);
> >
> >         p = buf + sizeof(buf);
> >         for (uint32_t v = i; v; v /= 10)
> >             *--p = '0' + (v % 10);
> >         EVP_DigestUpdate(copy, p, buf + sizeof(buf) - p);
> >         EVP_DigestUpdate(copy, "\n", 1);
> >         EVP_DigestFinal_ex(copy, digest, NULL);
> >         EVP_MD_CTX_free(copy);
> >         if (memmem(digest, sizeof(digest), needle, sizeof(needle)))
> >         {
> >             printf("counter width: %2u | n: %10u | i: %10u\n",
> > COUNTER_WIDTH, n, i);
> >             return 0;
> >         }
> >     }
> >     return 1;
> > }
> >
> > cc -DPOLYFILL -DCOUNTER_WIDTH=32 jk_evp.c -lssl -lcrypto -o jk_evp_msb_32
> > cc -DPOLYFILL -DCOUNTER_WIDTH=31 jk_evp.c -lssl -lcrypto -o jk_evp_msb_31
> > cc -DPOLYFILL -DCOUNTER_WIDTH=30 jk_evp.c -lssl -lcrypto -o jk_evp_msb_30
> > cc -DPOLYFILL -DCOUNTER_WIDTH=29 jk_evp.c -lssl -lcrypto -o jk_evp_msb_29
> > cc -DPOLYFILL -DCOUNTER_WIDTH=0 jk_evp.c -lssl -lcrypto -o jk_evp_0
> > counter width: 32 | n:  103832253 | i: 1588397616
> > counter width: 31 | n:   62413559 | i: 1003915120
> > counter width: 30 | n:  166340413 | i:  396135154
> > counter width: 29 | n:  137077701 | i:  171728193
> > counter width:  0 | n:  171728193 | i:  171728193
>
> I have to admit there is a bug in my previous code, it only works
> correctly for even numbers. It should have been:
>
> #define REVERTED_BIT(n, position, width) (((n & (1 << position)) >>
> position) << (width - position - 2 + (width & 1)))
>
> uint32_t revert_bits(uint32_t n, uint32_t width) {
>     uint32_t result = 0;
>     for (uint32_t i = 0; i < width; ++i) {
>         result |= REVERTED_BIT(n, i, width);
>     }
>     return result;
> }
>
> The actual performance measurements are:
> counter width: 32 | n:  103832253 | i: 1588397616
> counter width: 31 | n:  103832253 | i: 1588397616
> counter width: 30 | n:  166340413 | i:  396135154
> counter width: 29 | n:  166340413 | i:  396135154
> counter width: 28 | n:  268041599 | i: 2281045247 # 2**28 is close to
> the first finding when counting by incrementing the LSB, so this is
> slow.
> counter width: 27: This does not find anything, because 2**27 is lower
> than the first finding when counting by incrementing the LSB.
> counter width:  0 | n:  171728193 | i:  171728193 #
> math.log2(171728193) = 27.35555166834193

As an interim solution, it could make sense to leave small input unmodified, and to permute large texts to get rid of the natural language manifold.

Klaus Sembritzki· Jan 25, 2026, 14:21 UTC · re: Klaus Sembritzki · lore

Re: The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa

If vanilla-SHA256 continues to be used in vanilla-Git in the future, I suggest that platforms like GitHub hash internally.

On Sun, Jan 25, 2026 at 12:25 PM Klaus Sembritzki <klausem@gmail.com> wrote:
Show 191 quoted lines
>
> On Sun, Jan 25, 2026 at 10:47 AM Klaus Sembritzki <klausem@gmail.com> wrote:
> >
> > On Sat, Jan 24, 2026 at 10:25 AM Klaus Sembritzki <klausem@gmail.com> wrote:
> > >
> > > On Sat, Jan 24, 2026 at 8:28 AM Jeff King <peff@peff.net> wrote:
> > > >
> > > > On Fri, Jan 23, 2026 at 02:36:41PM -0800, Junio C Hamano wrote:
> > > >
> > > > > Jeff King <peff@peff.net> writes:
> > > > >
> > > > > > On Fri, Jan 23, 2026 at 09:16:46PM +0100, Klaus Sembritzki wrote:
> > > > > >
> > > > > >> $ # My initials (ks): 1aa
> > > > > >> $ echo ks | sha256sum
> > > > > >> $ 1aa44e718d5bc9b7ff2003dbbb6f154e16636d5c2128ffce4751af5124b65337
> > > > > >>
> > > > > >> $ # 50566750337
> > > > > >> $ echo thinking | sha256sum
> > > > > >> $ 50566750337beb9e98e553fd9196d10576f9eb0cbc6b66e2586b9d73af4f352f
> > > > > >
> > > > > > Oh man, I've got deadbeef!
> > > > > >
> > > > > >   $ echo jk35252822 | sha256sum
> > > > > >   33f1a74529870456c56ad97c59cfed6bdeadbeef9b9bc3f4ff49bb203e36f96b
> > > > > >
> > > > > > What could it all mean?
> > > > >
> > > > > Sorry, but I have to admit that I completely lack humor receptor
> > > > > cells.
> > > >
> > > > Probably because it was not that funny. :)
> > > >
> > > > The original message seemed to be looking for Numerology-style meanings
> > > > in random data. I wasn't sure if it was serious or not, but I could not
> > > > resist either playing along (if not) or trolling (if so).
> > > >
> > > > But here's my deadbeef brute-force program for fun.
> > > >
> > > > -Peff
> > > >
> > > > -- >8 --
> > > > #include <stdio.h>
> > > > #include <string.h>
> > > > #include <openssl/evp.h>
> > > >
> > > > int main(int argc, const char **argv)
> > > > {
> > > >         const char needle[] = { 0xde, 0xad, 0xbe, 0xef };
> > > >         const EVP_MD *algo = EVP_sha256();
> > > >         EVP_MD_CTX *ctx = EVP_MD_CTX_new();
> > > >
> > > >         EVP_DigestInit_ex(ctx, algo, NULL);
> > > >         while (*++argv)
> > > >                 EVP_DigestUpdate(ctx, *argv, strlen(*argv));
> > > >
> > > >         for (unsigned i = 0; ; i++) {
> > > >                 char buf[16];
> > > >                 char *p;
> > > >                 unsigned char digest[32];
> > > >                 EVP_MD_CTX *copy = EVP_MD_CTX_dup(ctx);
> > > >
> > > >                 p = buf + sizeof(buf);
> > > >                 for (unsigned v = i; v; v /= 10)
> > > >                         *--p = '0' + (v % 10);
> > > >                 EVP_DigestUpdate(copy, p, buf + sizeof(buf) - p);
> > > >                 EVP_DigestUpdate(copy, "\n", 1);
> > > >                 EVP_DigestFinal_ex(copy, digest, NULL);
> > > >                 EVP_MD_CTX_free(copy);
> > > >                 if (memmem(digest, sizeof(digest), needle, sizeof(needle)))
> > > >                         printf("%d\n", i);
> > > >         }
> > > > }
> > >
> > > Incrementing the MSB instead of the LSB (indexing naturally starts
> > > with 1 in that case) seems to improve the performance, and it finds
> > > different solutions, if the program is terminated early.
> > > The rationale is that there is autocorrelation in the observations,
> > > though I cannot judge what that means in this concrete example. The
> > > speedup is not that dramatic here, so SHA256 seems to be pretty
> > > random.
> > >
> > > #include <stdio.h>
> > > #include <string.h>
> > > #include <stdint.h>
> > > #include <openssl/evp.h>
> > >
> > > #ifdef POLYFILL
> > > EVP_MD_CTX *EVP_MD_CTX_dup(const EVP_MD_CTX *in)
> > > {
> > >     EVP_MD_CTX *out = EVP_MD_CTX_new();
> > >
> > >     if (out != NULL && !EVP_MD_CTX_copy_ex(out, in)) {
> > >         EVP_MD_CTX_free(out);
> > >         out = NULL;
> > >     }
> > >     return out;
> > > }
> > > #endif
> > >
> > > #define REVERTED_BIT(n, position, width) (((n & (1 << position)) >>
> > > position) << (width - position - 2))
> > >
> > > uint32_t revert_bits(uint32_t n, uint32_t width) {
> > >     uint32_t result = 0;
> > >     for (uint32_t i = 0; i < width; ++i) {
> > >         result |= REVERTED_BIT(n, i, width);
> > >     }
> > >     return result;
> > > }
> > >
> > > int main(int argc, const char **argv)
> > > {
> > >     const char needle[] = { 0xde, 0xad, 0xbe, 0xef };
> > >     const EVP_MD *algo = EVP_sha256();
> > >     EVP_MD_CTX *ctx = EVP_MD_CTX_new();
> > >
> > >     EVP_DigestInit_ex(ctx, algo, NULL);
> > >     while (*++argv)
> > >         EVP_DigestUpdate(ctx, *argv, strlen(*argv));
> > >
> > >     for (uint32_t n = 1; ; n++) {
> > > #if (COUNTER_WIDTH != 0)
> > >         uint32_t i = revert_bits(n, COUNTER_WIDTH);
> > > #else
> > >         uint32_t i = n;
> > > #endif
> > >         // printf("%u %u\n", n, i);
> > >         char buf[16];
> > >         char *p;
> > >         unsigned char digest[32];
> > >         EVP_MD_CTX *copy = EVP_MD_CTX_dup(ctx);
> > >
> > >         p = buf + sizeof(buf);
> > >         for (uint32_t v = i; v; v /= 10)
> > >             *--p = '0' + (v % 10);
> > >         EVP_DigestUpdate(copy, p, buf + sizeof(buf) - p);
> > >         EVP_DigestUpdate(copy, "\n", 1);
> > >         EVP_DigestFinal_ex(copy, digest, NULL);
> > >         EVP_MD_CTX_free(copy);
> > >         if (memmem(digest, sizeof(digest), needle, sizeof(needle)))
> > >         {
> > >             printf("counter width: %2u | n: %10u | i: %10u\n",
> > > COUNTER_WIDTH, n, i);
> > >             return 0;
> > >         }
> > >     }
> > >     return 1;
> > > }
> > >
> > > cc -DPOLYFILL -DCOUNTER_WIDTH=32 jk_evp.c -lssl -lcrypto -o jk_evp_msb_32
> > > cc -DPOLYFILL -DCOUNTER_WIDTH=31 jk_evp.c -lssl -lcrypto -o jk_evp_msb_31
> > > cc -DPOLYFILL -DCOUNTER_WIDTH=30 jk_evp.c -lssl -lcrypto -o jk_evp_msb_30
> > > cc -DPOLYFILL -DCOUNTER_WIDTH=29 jk_evp.c -lssl -lcrypto -o jk_evp_msb_29
> > > cc -DPOLYFILL -DCOUNTER_WIDTH=0 jk_evp.c -lssl -lcrypto -o jk_evp_0
> > > counter width: 32 | n:  103832253 | i: 1588397616
> > > counter width: 31 | n:   62413559 | i: 1003915120
> > > counter width: 30 | n:  166340413 | i:  396135154
> > > counter width: 29 | n:  137077701 | i:  171728193
> > > counter width:  0 | n:  171728193 | i:  171728193
> >
> > I have to admit there is a bug in my previous code, it only works
> > correctly for even numbers. It should have been:
> >
> > #define REVERTED_BIT(n, position, width) (((n & (1 << position)) >>
> > position) << (width - position - 2 + (width & 1)))
> >
> > uint32_t revert_bits(uint32_t n, uint32_t width) {
> >     uint32_t result = 0;
> >     for (uint32_t i = 0; i < width; ++i) {
> >         result |= REVERTED_BIT(n, i, width);
> >     }
> >     return result;
> > }
> >
> > The actual performance measurements are:
> > counter width: 32 | n:  103832253 | i: 1588397616
> > counter width: 31 | n:  103832253 | i: 1588397616
> > counter width: 30 | n:  166340413 | i:  396135154
> > counter width: 29 | n:  166340413 | i:  396135154
> > counter width: 28 | n:  268041599 | i: 2281045247 # 2**28 is close to
> > the first finding when counting by incrementing the LSB, so this is
> > slow.
> > counter width: 27: This does not find anything, because 2**27 is lower
> > than the first finding when counting by incrementing the LSB.
> > counter width:  0 | n:  171728193 | i:  171728193 #
> > math.log2(171728193) = 27.35555166834193
>
> As an interim solution, it could make sense to leave small input
> unmodified, and to permute large texts to get rid of the natural
> language manifold.

← back to recent threads