console.time() jots down the current time, if you do that twice and put stuff in the middle you get two times and the difference between them is how long that stuff took to do
console.timeEnd() uses the last execution of console.time() as the starting point to work out how long the stuff took to do
const originalUUID = crypto.randomUUID() generates a Universally Unique IDentifier, which can be thought of as a very large very random number, by use of a pseudorandom number generator
while(stuff) evaluates the stuff for truthiness (1 + 2 = 5 would be false, 50 < 200 would be true, ‘my username starts with the letter k’ would be true)
it’s typically followed by a ‘block’ of code, that is lines beginning with { and ending with }, but we don’t see that here, which means we can read while(stuff) as “keep checking if stuff is true in an endless loop, and only continue to the next line if one of the checks ends up being false”
the stuff here is creating another random UUID, and checking to see if it’s the same random number as the first one generated.
functions like this are so incredibly random that chancing upon two executions creating the same number should be practically impossible. staggeringly impossible. If so this code should never complete, as that while check would be endless, never finding a match
the image suggests that one such match was found in about 19 million milliseconds (a bit over 5 hours). this is probably faked, because the absurd unlikelihood of the same number being generated in so much as a single human lifetime, let alone a day, is laughable
the imagine is faked or something is terribly wrong with their pseudorandom number generator
But you can’t say that it’s fake or broken just because it’s unprobable, unless there’s supposed to be some additional safe guards to prevent the same random value from repeating within a certain distance from itself.
from a practical engineering standpoint, no, it’s impossible
I’m pedantic as they come, but pedantry has little use in an engineering discipline, software engineering included
like, if I take a cup of water and pour it into the Pacific Ocean strictly speaking I can say I “single-handed raised the water level of the ocean” and you’d be correct in the most unhelpful way
for the code in question if the PRNG is working as expected then for all meaningful purposes it can be considered impossible
edit
oh also to fight pedantry with pedantry, technically even a check that would prevent duplicates might not prevent duplicates because you could argue there’s a non-zero chance a random cosmic ray flips just the right bit at just the right moment rendering even that pure chance. anything engineered (and not pure mathematical theory) has to draw the line of plausibility somewhere because we’re engineering inside of a chaotic reality. drawing the line to say that the image above is functionally impossible is just fine.
The function first generated a random UUID. This is a long string of random characters, used in many software systems to uniquely fingerprint things, transactions for example. In theory, you can have millions of seperate systems, each generating UUIDs all the time without ever having to worry about a collision (a collision is one or more systems generating the same UUID, therefore it being not unique anymore)
The second line then runs UUID generation again, trying to generate an identical UUID to the one it already made. Tis is absurd because even a dmsupercomputer trying to generate identical UUIDs would take longer than the lifespan of the universe.
The console line shows that a matching UUID was apparently found after some amount of time, which shouldn’t be possible, implying some fuckery with the random number generator.
They’re basically trying to find the time to create duplicate UUIDs. UUIDs are randomly generated and assumed to be so unique and actually random across… well, everything, that no one even checks if they’re actually unique. They suggested they found one in 5 hours. The only maybe possible way I could think of to do this legitimately is to use some ridiculously powerful computer and still get very lucky.
Ah! And this is why I don’t really care that much about long passwords or things of that nature. If the attack is brute force, it could still get lucky and guess it in 5 hours just like this UUID thing!
The chance to get lucky and pick a long, random password is still ridiculously small. The chance to pick admin123 is ridiculously large. You see the difference?
With this logic you could say the chance to hit the lottery jackpot is the same as if the numbers are just 3 digits long. It’s not trying all the possible combinations all at once.
If the password was forced to be a specific length and could not be shorter or longer, it would be the same as that. But they’re not usually forced to be a specific length. They do have bounds, but that also makes it so there are fewer possible combinations to guess.
I don’t understand
console.time()jots down the current time, if you do that twice and put stuff in the middle you get two times and the difference between them is how long that stuff took to doconsole.timeEnd()uses the last execution ofconsole.time()as the starting point to work out how long the stuff took to doconst originalUUID = crypto.randomUUID()generates a Universally Unique IDentifier, which can be thought of as a very large very random number, by use of a pseudorandom number generatorwhile(stuff)evaluates the stuff for truthiness (1 + 2 = 5 would be false, 50 < 200 would be true, ‘my username starts with the letter k’ would be true) it’s typically followed by a ‘block’ of code, that is lines beginning with{and ending with}, but we don’t see that here, which means we can readwhile(stuff)as “keep checking ifstuffis true in an endless loop, and only continue to the next line if one of the checks ends up beingfalse”the
stuffhere is creating another random UUID, and checking to see if it’s the same random number as the first one generated.functions like this are so incredibly random that chancing upon two executions creating the same number should be practically impossible. staggeringly impossible. If so this code should never complete, as that
whilecheck would be endless, never finding a matchthe image suggests that one such match was found in about 19 million milliseconds (a bit over 5 hours). this is probably faked, because the absurd unlikelihood of the same number being generated in so much as a single human lifetime, let alone a day, is laughable
the imagine is faked or something is terribly wrong with their pseudorandom number generator
But you can’t say that it’s fake or broken just because it’s unprobable, unless there’s supposed to be some additional safe guards to prevent the same random value from repeating within a certain distance from itself.
from a purely mathematical standpoint, yes
from a practical engineering standpoint, no, it’s impossible
I’m pedantic as they come, but pedantry has little use in an engineering discipline, software engineering included
like, if I take a cup of water and pour it into the Pacific Ocean strictly speaking I can say I “single-handed raised the water level of the ocean” and you’d be correct in the most unhelpful way
for the code in question if the PRNG is working as expected then for all meaningful purposes it can be considered impossible
edit oh also to fight pedantry with pedantry, technically even a check that would prevent duplicates might not prevent duplicates because you could argue there’s a non-zero chance a random cosmic ray flips just the right bit at just the right moment rendering even that pure chance. anything engineered (and not pure mathematical theory) has to draw the line of plausibility somewhere because we’re engineering inside of a chaotic reality. drawing the line to say that the image above is functionally impossible is just fine.
We M-x butterflying now
Oh wow thank you
Insanely unlikely giant random number matches other insanely giant random number
The function first generated a random UUID. This is a long string of random characters, used in many software systems to uniquely fingerprint things, transactions for example. In theory, you can have millions of seperate systems, each generating UUIDs all the time without ever having to worry about a collision (a collision is one or more systems generating the same UUID, therefore it being not unique anymore)
The second line then runs UUID generation again, trying to generate an identical UUID to the one it already made. Tis is absurd because even a dmsupercomputer trying to generate identical UUIDs would take longer than the lifespan of the universe.
The console line shows that a matching UUID was apparently found after some amount of time, which shouldn’t be possible, implying some fuckery with the random number generator.
I wish I was a good enough coder to understand what’s going on, too. I bet it’s funny as hell.
They’re basically trying to find the time to create duplicate UUIDs. UUIDs are randomly generated and assumed to be so unique and actually random across… well, everything, that no one even checks if they’re actually unique. They suggested they found one in 5 hours. The only maybe possible way I could think of to do this legitimately is to use some ridiculously powerful computer and still get very lucky.
Ah! And this is why I don’t really care that much about long passwords or things of that nature. If the attack is brute force, it could still get lucky and guess it in 5 hours just like this UUID thing!
The chance to get lucky and pick a long, random password is still ridiculously small. The chance to pick admin123 is ridiculously large. You see the difference?
Length doesn’t matter if it’s randomly trying every possible combination. It could just as easily guess the longest possible password as the shortest.
Other methods of attack would be a good reason to make it long and nonsensical; not a random brute force attack.
With this logic you could say the chance to hit the lottery jackpot is the same as if the numbers are just 3 digits long. It’s not trying all the possible combinations all at once.
If the password was forced to be a specific length and could not be shorter or longer, it would be the same as that. But they’re not usually forced to be a specific length. They do have bounds, but that also makes it so there are fewer possible combinations to guess.
OK if you say so.
Here are some suggestions for your next password https://www.comparitech.com/news/minecraft-qwerty-and-india123-among-2025s-most-common-passwords-report/