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

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

[Klaus Sembritzki]

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

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

[Jeff King]

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

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

[Marc Branchaud]

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:
> 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
> 

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

[Junio C Hamano]

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.

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

[Klaus Sembritzki]

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

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

[Jeff King]

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);
	}
}

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

[Klaus Sembritzki]

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

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

[Klaus Sembritzki]

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

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

[Klaus Sembritzki]

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.

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

[Klaus Sembritzki]

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