- Feature Articles
- CodeSOD
-
Error'd
- Most Recent Articles
- Stop Poking Me!
- Operation Erred Successfully
- A Dark Turn
- Nothing Doing
- Home By Another Way
- Coast Star
- Forsooth
- Epic
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
:rolleyes:
Admin
Maybe it's a homage to Grandmaster Flash? "It's like a jungle sometimes it makes me wonder / How I keep from going under"
Admin
Depends very much on the TYPE of Guid. Type 4 Guids are 122 bit random numbers and their "quality" as a Guid is directly correlated to the randomness of the generator.
There are almost no implementations today which still use Type 1 Guids.
Admin
A real Rube Goldberg machine would do the actual work across at least six classes with the deepest twelve function calls deep. That's how it is in parts of our codebase!
Admin
Admin
Challenge accepted! If I had the time, at least
Admin
I feel shamed. Though you did forget the wooden table!
Admin
There’s probably a node.js module somewhere on GitHub which does that...
Admin
Something like this? https://github.com/lwille/node-gphoto2
Batteries, camera or wooden table not included.
Admin
But that depends on an implementation detail. It would be just as wrong as using a Guid to figure out a computer's MAC address twenty years ago.
Admin
as someone who enjoys working with NodeJS..... there's a lot of things that people use NodeJS for that make absolutely no sense whatsoever....
Admin
well not quite.... they aren't pure random there's one hex digit that's fixed and another that's got some sort of odd requirement that i'm not sure what it means....
Files under: http://jsperf.com/node-uuid-performance/19
Admin
According to RFC4122, that
y
is the first four bits of theclock_seq_hi_and_reserved
field; what it's used for, no idea.Admin
i am enlightened. i know know what it means.... still NFC what it's used for.
but i do know that discourse will reject a UUID that sets the bits in that place wrong (i did try without the bitwise math and if the bits got messed up for that digit discourse wouldn't talk to my bot.)
Admin
It's a requirement of v4 GUIDs, so in that case, Discourse is doing it ri- *universe implodes*
Admin
it's more likely they're parsing it using a built in ruby UUID parser (for raisins) and that's what's blowing up.
maybe @riking cna confirm or refute that theory?
Admin
Admin
but that's doing it right!
an excellent point.
would one of our lovely local TL4 users kindly jeff these UUID posts to a new topic?
Admin
Worth mentioning is that in some random number generation libraries seeding is a no-op, because the amount of entropy they can pull out of /dev/random is much greater than any number seed a programmer could easily come up with.
One that I think might be worth trying to generate random passwords, though, just to see what would happen:
Admin
http://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm
Admin
Even when the programmer wants a reproducible series of pseudo-random numbers every invocation?
Admin
If you want a specific series of numbers, say, for testing purposes, mock out your random-number function to give you that series of numbers.
Admin
Not a terribly good idea. Pseudo random numbers (the ones that require a seed) don't use any stored system entropy. If you want a pseudo-random and the system gives you a true random in its place (/dev/random[1]), then you may be harming either the security or the performance of the entire system.
[1] The current implementation of /dev/random isn't a deterministic pseudo-random sequence on most distributions.
Admin
Genius!
This needs to be paired with the 400+ lines of code I found in the legacy codebase I am working on, which manually hashes (and "dehashes") a password into 24 digits separated by hyphens (eight groups), in client application code (not in the DB or server) in order to store the password in a "secure" form in the DB which is on the users computer.
Even if the developer really found value in this method of hashing (instead of using one of the built-in hashing functions which are more secure), all 400 lines of code could be replaced with about 40 lines of code, at most, to achieve the same result.
But that would have been too easy and would not show up as many many lines of code (I swear my predecessors got paid by the lines of code they created).
Admin
Real PRNGs all support generating a seeded sequence. The system entropy source is just used (sometimes) as a seed for the PRNG, often for the default “unseeded” configuration.
Admin
Because then I'd rather like to know the name of this product so I never put any passwords in it. I don't want any hobyist encryption scheme leaking out information (although I'd likely generate a unique password anyway, don't want to take any chances).
Admin
That's probably it, it tries to parse the Version field and your uuid has an invalid version, so it throws.
Admin
good enough for me! :-D
Admin
Which would be quite WTFy if you actually need your RNG to put out a random, but consistent sequence. Say, a game with random starting conditions - if you like the map, you can store the seed and come back to it later, and you don't have to write your own pseudo-RNG.
Admin
That would not be a RNG; that would be a PRNG.
Doing It Wrong. Whatever language you're using1, it already has a PRNG library function. Use it.1 For reasonable values of "whatever." I'm sure languages can be found that don't have one (BIT? Brainfuck? Whitespace?) If you're using a language that doesn't have one, use a different language.
Admin
Suggests to me the opposite idea: The ultimate, absolutely cannot be dehashed, password hash. Everything hashes to a half-bit; a 1. So there is absolutely, positively no way to determine the original password from the hash.
"Security," you say? Well who cares about that?
Admin
Admin
What if you're writing the implementation of a language? You don't always want to just use the PRNG from the underlying language; for example, the PRNG in the standard C library is not thread-safe in a nice way (there are replacements that are better, but then you're not writing portable code and that has other headaches).
Getting PRNGs right is remarkably difficult.
Tangentially, getting true RNGs right is even harder, by several orders of magnitude. The real difficulty is in testing; as with anything related to security, it's easy to come up with code that you can't find problems in, but really hard to ensure that nobody else can find issues…
Admin
That's a different beast. The context of the post to which I was replying was writing your own (P)RNG for an application. I think we can agree that would be doing it wrong, yes?
Admin
No. :smiley: There are three main types of (P)RNG usage.
Cases #1 and #2 are the ones generally accepted as needing care. Case #3 doesn't usually (except sometimes it does, threaded programming being what it is).
Admin
fiiiiine! i'll rewrite it.....
why teh frack was that detected as vbscript and why does vbscript frack up the formatting so much‽‽‽‽
Admin
And the block after that will just ignore non-numeric characters anyway!
Admin
I know this is a complete nitpick but that's what I do (and in some jobs it pays well).
For every single bit of a random number, "as difficult as possible" is p=0.5. The probability of guessing a random number of n bits is simply 1/(2^n). The requirement is that the generation of every single bit be independent of the bits generated so far.
Admin
Specifically, it's that the chance of you guessing a bit is 0.5 even when you've got a good history of the previously generated bits and know the algorithm. That's really difficult.
Admin
Random bits are available for free on the Internet.
Admin
This always rings my alarm bells - if I ever see, "we performed our MCS in the Cloud for extra-specialness..." I will probably lose it completely.
Admin
Which is what makes encryption so difficult. Because regardless of how it might look like p=0.5 to the attacker, every bit must really be input driven with p=1.0 to permit decryption.
Admin
Real randomness is used to generate keys.
Admin
Yup, that's one up from my "The requirement is that the generation of every single bit be independent of the bits generated so far." If I had a history of all the bits generated and knew the algorithm, would that make a difference? If I did and the next bit is equiprobable, then the algorithm must be truly random. But if I have a good but partial history, it might be that, knowing the algorithm, the answer depends on how long it would take to run the algorithm from all possible seeds and find the bit sequence in the history. It's all a bit Borges Library at this point.
My nitpick, however, was based on the use of the word "random". Random is random. No matter how clever the algorithm, if it exists than the result must be pseudo-random.
In the Good Old Days we used to generate random numbers using the noise of special avalanche diodes, small radioactive sources, or suitably designed electron tubes. The original British government lottery, Premium Bonds, used (I believe) an electron tube as a random generator. But they were all power hungry and have the disadvantage that they can't be made pseudorandom. [edit - corrected - @tarunik points out that a radioactive RNG can be low power nowadays. However, the Hotbits RNG linked to by @Jaime is neither particularly compact - it uses a small GM tube - nor particularly low power.]
Admin
And such approaches are still viable today -- I'd personally go with a noise diode, myself, as such could be integrated onto an IC easily ;)
And last I checked, radioactive sources aren't power hungry, considering you can use a solid-state detector to pick up radioactivity.
Admin
Admin
Aye -- I once floated with my college roommate a similar idea based on an Americium-241 source and mounted to an add-in card, with dedicated H/W doing the timing, and returning the inter-decay intervals directly as random numbers instead of thresholding them to generate a random bitstream.
Admin
pm;
Admin
Or it could use a camera to take a snapshot of an old TV tuned to a channel that's not operating, collect the visual static, parse it, and keep trying until it ends up being a url to a website that generates random passwords.
Admin
Fair comment, and I am about to correct to read "were" power hungry.
I wouldn't want to integrate a noise diode onto a modern digital IC myself. Different technology.