* The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa @ 2026-01-23 20:16 Klaus Sembritzki 2026-01-23 21:06 ` Jeff King 0 siblings, 1 reply; 10+ messages in thread From: Klaus Sembritzki @ 2026-01-23 20:16 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa 2026-01-23 20:16 The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa Klaus Sembritzki @ 2026-01-23 21:06 ` Jeff King 2026-01-23 21:57 ` Marc Branchaud 2026-01-23 22:36 ` Junio C Hamano 0 siblings, 2 replies; 10+ messages in thread From: Jeff King @ 2026-01-23 21:06 UTC (permalink / raw) To: Klaus Sembritzki; +Cc: git 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa 2026-01-23 21:06 ` Jeff King @ 2026-01-23 21:57 ` Marc Branchaud 2026-01-23 22:36 ` Junio C Hamano 1 sibling, 0 replies; 10+ messages in thread From: Marc Branchaud @ 2026-01-23 21:57 UTC (permalink / raw) To: git 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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa 2026-01-23 21:06 ` Jeff King 2026-01-23 21:57 ` Marc Branchaud @ 2026-01-23 22:36 ` Junio C Hamano 2026-01-23 23:30 ` Klaus Sembritzki 2026-01-24 7:28 ` Jeff King 1 sibling, 2 replies; 10+ messages in thread From: Junio C Hamano @ 2026-01-23 22:36 UTC (permalink / raw) To: Jeff King; +Cc: Klaus Sembritzki, git 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa 2026-01-23 22:36 ` Junio C Hamano @ 2026-01-23 23:30 ` Klaus Sembritzki 2026-01-24 7:28 ` Jeff King 1 sibling, 0 replies; 10+ messages in thread From: Klaus Sembritzki @ 2026-01-23 23:30 UTC (permalink / raw) To: Junio C Hamano; +Cc: Jeff King, git 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. > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa 2026-01-23 22:36 ` Junio C Hamano 2026-01-23 23:30 ` Klaus Sembritzki @ 2026-01-24 7:28 ` Jeff King 2026-01-24 9:25 ` Klaus Sembritzki 1 sibling, 1 reply; 10+ messages in thread From: Jeff King @ 2026-01-24 7:28 UTC (permalink / raw) To: Junio C Hamano; +Cc: Klaus Sembritzki, git 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); } } ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa 2026-01-24 7:28 ` Jeff King @ 2026-01-24 9:25 ` Klaus Sembritzki 2026-01-25 9:47 ` Klaus Sembritzki 0 siblings, 1 reply; 10+ messages in thread From: Klaus Sembritzki @ 2026-01-24 9:25 UTC (permalink / raw) To: Jeff King; +Cc: Junio C Hamano, git 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa 2026-01-24 9:25 ` Klaus Sembritzki @ 2026-01-25 9:47 ` Klaus Sembritzki 2026-01-25 11:25 ` Klaus Sembritzki 0 siblings, 1 reply; 10+ messages in thread From: Klaus Sembritzki @ 2026-01-25 9:47 UTC (permalink / raw) To: Jeff King; +Cc: Junio C Hamano, git 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa 2026-01-25 9:47 ` Klaus Sembritzki @ 2026-01-25 11:25 ` Klaus Sembritzki 2026-01-25 14:21 ` Klaus Sembritzki 0 siblings, 1 reply; 10+ messages in thread From: Klaus Sembritzki @ 2026-01-25 11:25 UTC (permalink / raw) To: Jeff King; +Cc: Junio C Hamano, git 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa 2026-01-25 11:25 ` Klaus Sembritzki @ 2026-01-25 14:21 ` Klaus Sembritzki 0 siblings, 0 replies; 10+ messages in thread From: Klaus Sembritzki @ 2026-01-25 14:21 UTC (permalink / raw) To: Jeff King; +Cc: Junio C Hamano, git 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2026-01-25 14:22 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-01-23 20:16 The SHA256 of "xy\n" (ASCII, no CRLF) contains 1337, ACBAD in za, and I am 1aa Klaus Sembritzki 2026-01-23 21:06 ` Jeff King 2026-01-23 21:57 ` Marc Branchaud 2026-01-23 22:36 ` Junio C Hamano 2026-01-23 23:30 ` Klaus Sembritzki 2026-01-24 7:28 ` Jeff King 2026-01-24 9:25 ` Klaus Sembritzki 2026-01-25 9:47 ` Klaus Sembritzki 2026-01-25 11:25 ` Klaus Sembritzki 2026-01-25 14:21 ` Klaus Sembritzki
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox