I remember seeing one of these for Bitcoin addresses a long time ago... Very funny :)
Every V4 UUID
201–210 of 381 posts
Re: Every V4 UUID
#202how many sequential chars of a uuid do you need to calculate the rest of it, or infer the rest of it from a smaller set of all possible ones?
All of them, more or less. There are a few marker bits but the rest are pure data. There is no error correct or redundancy.
Re: Every V4 UUID
#203Re: Every V4 UUID
#204Re: Every V4 UUID
#205Earlier quoted context omitted.
I'm really happy that the trick was magical to you - I was so surprised and delighted when I realized that this was possible, and I wasn't really sure if anyone else would feel the same way! And of course, I'm proud to be providing so much utility here - finally we can find and use UUIDs tailor-fit to our needs
Memorable UUIDs? I think you're on to something here! (Also, dibs on 00000000-0000-4321-abcd-000000000001!)
The most offensive sentence I could come up with leetspeak/hexspeak is this one:
fe11a710-babe-4150-ace5-b19b1accd1cc
(I am so sorry)
Re: Every V4 UUID
#206Please remove my UUID 039a69dc-b0a1-4be0-b424-5e45aca8d3fb from the list. I spent a lot of money on it
Re: Every V4 UUID
#207Re: Every V4 UUID
#208Earlier quoted context omitted.
It’s an interesting question whether that could be fixed. I think the answer is Yes. If the author didn’t do any scrambling, and just displayed UUIDs in numeric order, then it’s trivial to enumerate search results in order. Likewise, if you do something like adding a constant mod 16 to each hex digit, you could do the same thing when you generate UUIDs matching a substring. So the question becomes whether you could f…
FWIW I am super interested in this question but feel like I don't know how to derive a satisfying answer, maybe because the one of my goals here (add "enough" entropy) is a real fuzzy "I know it when I see it" sort of thing. But I'm gonna try to get a few more crypto-knowledgeable friends to chat with me about this and write up what I learn!
My first thought was to use linear transformations over Z_2 as a field, as that would create a natural interpretation of fixing certain bits as taking a linear subspace. Interestingly this leads to the property that XOR is preserved.
I implemented this in a very quick and hacky way for 32 bits. I generated a random boolean matrix M invertible in Z_2. To turn an input number x into a corresponding number y in an N-bit space, I convert x to binary and turn that into a vector of 1s and 0s, then multiply it by that randomized matrix to get y. Here are the first few y's corresponding to x=0, 1, ...:
00000000000000000000000000000000
0xx0x000xx00x0xx000xxx00xxx0x000
x0xx000xxxx0xxx00x000xxx0xx0xx0x
xx0xx00x00x00x0x0x0xx0xxx0000x0x
x0xx0x00xxx0xx0x00xx0x0xx0xx00x0
xx0xxx0000x00xx000x0x00x0x0xx0x0
00000x0x000000xx0xxx00x0xx0xxxxx
0xx0xx0xxx00x0000xx0xxx000xx0xxx
...
(Hoping the non-monospace font doesn't ruin the alignment too much.)
Which looks... random-ish? I expect that turning these into UUIDs may result in more random-looking sequences.
Not sure how to solve the problem of search with this, but the hope would be that the linear structure gives you what you need, since fixing bytes on UUIDs should correspond to considering linear subspaces of the y vectors. Perhaps this can also be used to apply lexicographic order on the corresponding x vectors (i.e.: ordering the indexes), so that you could jump to each UUID matching the search in order.
Re: Every V4 UUID
#209Earlier quoted context omitted.
My card doesn't even let me include repeating digits in its PIN. I suppose it can make a one-off guess more likely than one in a thousand to correctly guess my PIN.
Is it repeating in the whole PIN, or in digits next to each other? I'm trying to resist the nerd snipe of what the total number of possibilities would be in the latter case...
I believe it would be 7290, or more generalized, S(N) = 10 * 9 ^(N-1) with N being the length of the code and S being the number of combinations (assuming that a decimal system is used)
And from there, with variable lengths ranging from L to H, S(L, H) = 5/4 * 9 ^(L-1) * (9^(U-L+1) - 1)
So if the bank allows combinations from 4 - 6 digits, there would be a total of 663390 combinations to choose from.
Now, of course, the bank may decide to go from decimal to hexadecimal in the future - or maybe, there systems allow only duodecimal. In any case, the formula can be generalized further to account for all number systems - with B being the base of the system:
S(L, H, B) = (B/(B-2)) * (B-1) ^(L-1) * ((B-1)^(U-L+1) - 1)
This is only defined for B > 2 - in binary system, there's only ever two combinations which fit the constraint
Re: Every V4 UUID
#210how many sequential chars of a uuid do you need to calculate the rest of it, or infer the rest of it from a smaller set of all possible ones?
All of them, more or less. There are a few marker bits but the rest are pure data. There is no error correct or redundancy.
I didn't think v4 uuid's were completely random over that 128bit space for some reason, and this was wrong, but interestingly.
for a uuid like 414c1bde-b676-4242-be35-887f01a24f10, if I take its suffix 887f01a24f10 (12 chars, 48 bits) there are still 19 chars (76 bits) to the left of it. (barring the constant 13th char identifier 4)
There still are 2^76 uuid's with that suffix to search through. It made sense with ipv6 addresses and cryptography, but for some reason I had this idea that uuid's didn't use an CRNG that covered the whole 128 bit space. A lot of wrong stuff rattling around in my memory for some reason, thanks for clarifying.