Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Every V4 UUID

everyuuid.com

Post reply on HN
Print view View original

301–310 of 381 posts

Re: Every V4 UUID

#301

Post by dzaima »

A "proper" search while still retaining sufficiently-looking randomness might be achievable via an SMT solver, by asking it to find an index above the current position, below a binary-searched top boundary, that contains the search term. I think SMT solvers should be clever enough to be able to work the search around some ciphers.

Maybe an SMT solver is a rather heavy-weight approach, but I think it fits the task of searching through 2^122 values :)

Edit: even with no cipher, it takes said approach ~1.6s to find that after 0x1067D3DC2F4951AEA8DB8D0108D7D65 the first occurrence of 0xABCD is at 0x1067D3DC2F4951AEA8DB8D0108DABCD with Z3 (cvc5 and Bitwuzla are slightly slower), which is perhaps a bit too slow.. perhaps it could be improved to something more reasonable by restricting the search to near the end until that fails, and reducing the matchable positions based on the dashes, but that's back to effort.

Edit 2: slightly more effort later:

    cipher:   0x15FD586DF0CE258730098B94325ACE7 * (val ^ 0x93C324915DB2B3C4D4CD8135C0DDF1)
    inverse: (0x1D52334877384DE3A6DAA4A3312A6D7 * val) ^ 0x93C324915DB2B3C4D4CD8135C0DDF1

    example first 10 entries:
      0: 2839676B79617D5B9FDF9D43CFB3077
      1: 123C0EFD889357D46FD611AF9D58390
      2: 143418475AFDC869FFF2B46C3468A45
      3: 3E36BFD96A2FA2E2CFE928D8020DD5E
      4: 002EC9233C9A13786005CB94991E413
      5: 2A3170B54BCBEDF12FFC400066C372C
      6: 2C2979FF1E365E86C018E2BCFDD3DE1
      7: 162C21912D6838FF900F5728CB790FA
      8: 18242ADAFFD2A995202BF9E562897AF
      9: 0226D26D0F04840DF0226E51302EAC8

    binary search max set to `10 * 2**search_bit_width` after after the chosen start
    trying to find a match only in the last 3 possible places (i.e. searching WXYZ only matches *****WXYZ, ****WXYZ*, ***WXYZ**)
    searching for 0xFF00FFCC after index 0xAAAAAAAAAAAAAA:
      nearest match found at: 0xAAAAAAAD04E3DA
      ciphered: 0x0E9399CC39B716BC96348AFF00FFCCD
      time taken: 0.7s (bitwuzla or cvc5), or 1s (z3)
But alas I'm stupid, and searching doesn't care about lexicographic ordering, and you necessarily have to search all possible places, not just the end, and that's a ton slower. Perhaps dash placement could reduce them enough, but that's even more effort.

Re: Every V4 UUID

#302

Post by soheil »

vivzkestrel wrote: post #278
tobyjsullivan wrote: post #21

The fact that the search works impressed me more than anything. Of course, like every great magic trick, it seems so simple once it is explained. For the curious, here's the linked blog post describing how the project works: https://eieio.games/blog/writing-down-every-uuid/ Edit to add: I'd only tried searching for an exact UUID when I wrote this comment. I didn't realize it supports full text search! Now I'm even mo…

For the even more curious, UUID has 5316 decillion 911 nonillion 983 octillion 139 septillion 663 sextillion 491 quintillion 615 quadrillion 228 trillion 214 billion 121 million 397 thousand 304 values. Imagine the fact that there aren't as many kms to reach GN-Z11 (farthest known galaxy in the Universe I think) as there are digits above

yet I was able to scroll through them like scrolling through a 800-word web page

Re: Every V4 UUID

#303

Post by martijnvds »

flkiwi wrote: post #216
cubefox wrote: post #205

Earlier quoted context omitted.

The most offensive sentence I could come up with leetspeak/hexspeak is this one: fe11a710-babe-4150-ace5-b19b1accd1cc (Yes it's a valid UUID) (I am so sorry)

Terrible day to be a very specific kind of literate.

You could call it.. l33terate

Re: Every V4 UUID

#304

Post by naranha »

If the browser has 1080 vertical pixels, the scrollbars has max say 1000 possible positions. According to my napkin math* if you scroll over 100 uuids per second it would take up to ~1.7 septillion or ~1 700 000 000 000 000 000 000 000 years to scroll to an uuid of which you know the position if you hit the spot exactly on the scrollbar.

* https://www.wolframalpha.com/input?i=ROUND%5B2%5E122%2F1000%...

Edit: Use 122 bit instead of 128 due to UUIDv4

Re: Every V4 UUID

#305

Post by usr1106 »

efitz wrote: post #96

I’m writing a script that scrolls through the site, scrapes the UUIDs, and stores them in an AWS S3 bucket. I’ll let you know when it finishes.

What will be the bill?

Re: Every V4 UUID

#307

Post by [deleted] »

jiggawatts wrote: post #231
quietbritishjim wrote: post #179

Earlier quoted context omitted.

Are you really worried that a card machine is going to leak your PIN? That doesn't seem to be a common attack vector compared to a third-party skimmer being attached or someone just mugging you and demanding your PIN under threat of physical violence. To answer the actual question: I don't know because I left my PIN at 4 digits, despite knowing I could use more, precisely because I didn't think it would really make m…

I'm not worried specifically about the PIN leaking. The concern is that a 4-digit max PIN length is certainly implemented by someone who couldn't be bothered to read the spec for secure credit card transaction handling. It's the equivalent of the "No brown M&Ms" clause or "Canary in the coal mine" test. Nobody actually cares about the M&M color or some dumb bird.

[deleted]

Re: Every V4 UUID

#308

Post by quietbritishjim »

jiggawatts wrote: post #231
quietbritishjim wrote: post #179

Earlier quoted context omitted.

Are you really worried that a card machine is going to leak your PIN? That doesn't seem to be a common attack vector compared to a third-party skimmer being attached or someone just mugging you and demanding your PIN under threat of physical violence. To answer the actual question: I don't know because I left my PIN at 4 digits, despite knowing I could use more, precisely because I didn't think it would really make m…

I'm not worried specifically about the PIN leaking. The concern is that a 4-digit max PIN length is certainly implemented by someone who couldn't be bothered to read the spec for secure credit card transaction handling. It's the equivalent of the "No brown M&Ms" clause or "Canary in the coal mine" test. Nobody actually cares about the M&M color or some dumb bird.

Ok, but that doesn't answer my question: what specific problem are you worried about that would allow someone to steal your money, that isn't incomparably unlikely compared to other methods? I'm just not aware of any problem that has happened in practice from poorly written card reader software.

Re: Every V4 UUID

#309

Post by tills13 »

gibibit wrote: post #170
Arch-TK wrote: post #120

Wow, it's a website which has more than a screen-full of stuff on it at one time and scrolling doesn't introduce a seconds-long loading animation. I wonder if modern web developers of modern web applications could somehow harness this technology.

100% this. I thought the same thing immediately, "wow, this is fast and smooth and responsive!!" It's ludicrous how our computer hardware is 1000x faster than it was 30 years ago in 1995, but software is so bloated that it is still slower! Relevant: "Will Software Stop Getting Slower?" Jonathan Blow https://www.youtube.com/watch?v=4ka549NNdDk

It's merely a trick of windowed scrolling.
Post reply on HN