« first day (3211 days earlier)      last day (1761 days later) » 

00:00
Well, I should not go into too much detail. But there were some usability issues with TRUE_RANDOM and PSEUDO_RANDOM: users were very prone to only use the former, while PSEUDO_RANDOM was probably the right one for them.
Ugh. Can we invent an English word that means something more along the lines of "unpredictable" to use instead of "random". Too much philosophical and metaphysical silliness associated with random.
I also want "true" random to stop being a thing. I try to nudge people into using "hardware" random, "secure" random, and only use PRNG when I can't think of anything better.
As long as people don't get the underlying concepts we can only steer them into the right direction.
Good documentation would probably go a long way. IN the TRUE_RANDOM case you could put something like: don't use this unless you want to seed your own random number generator or are OK with blocking your application.
"Deterministic RNG" I suppose. I know I've used that one before. I can't remember why, when, or if it was ever less appropriate than "PRNG" (outside more formal cryptography communications) though.
How about BLOCKING_RANDOM?
Yeah, that might be a good one.
Then there is that conversation about "Random" and "SecureRandom" vs "InsecureRandom" and "Random". I agree with the sentiment but as a programmer I see the need for better names than the latter pair.
00:12
and I like RBG instead of RNG, because now there are RNG's that only output binary, which is, well, weird.
I'd use a single Random.create() and by default return the secure one. That way you can work around it.
Functionality is identical after all.
Not that it helped for Java, everybody still used "SHA1PRNG" even when it wasn't secure (and it is still not fully documented, if I'm not mistaken)
Dang still haven't found PBT keycaps for my UHK :(
I thought now "SHA1PRNG" was basically just a synonym for "default". And so it's always going to stay undocumented in terms of Java standards stuff.
Hmm. I can only remember the Harmony project's buggy SHA1PRNG. I half remember there being another issue, but can't recall the specifics at all now.
It isn't. It's a specific counter based PRNG by Sun. And on Android they used the old Apache classpath one, which was a broken implementation of it. Then they switched to OpenSSL, which meant that you would get something completely different. Funny enough, that meant that setSeed worked differently, which broke all kinds of programs that relied on that to get a deterministic PRNG... LOL
All the while, just new SecureRandom() would have completely removed all those problems.
Yeah, it was Harmony.
They now have "DRBG" too as algorithm. I'm not happy about it because it represents one of NIST's DRBG's, and it is of course not deterministic once it gets seeded. And it is seeded.
Fortunately, most people won't have a clue what DRBG means anyway.
00:28
They decided that all instances of SecureRandom would be non-deterministic and that any implementation that was would be considered broken, wasn't it? Now setSeed is always supposed to mix in data instead of initialize. (I'm irritated that people consider this seeding. It doesn't seem helpful. But this definition exists outside of Java, too.)
When toying with writing a random number API, I decided that non of my method names would contain the word "seed". I think I used "initialize" instead. And parameters could only be named "seed" if they were part of an initialization function.
00:45
Well if they would just have used reseed or even mixInSeed then it would already be much more clear. I suppose they used the seeding trick for testing and stuff, but it is very dangerous. I also have a thing against cryptographers telling people to use a CSPRNG when they actually mean the key stream of a stream cipher. CSPRNG's tend to reseed...
Besides that, you should then create a definition which information is returned by the CSPRNG. What if somebody switches over to my Optimized Simple Discard Method for numbers? The numbers would suddenly be all different!
While the functions would still nicely fit their contracts.
@SqueamishOssifrage Did you have a look at the Optimized Simple Discard Method yet? I know it is not much to look at, but it is a really simple optimization.
You could decouple RBGs from sampling algorithms. OSDM.sampleInteger(result, limit, rbg)
Ugly, but...
Um, yeah, maybe not that user friendly :)
On the other hand you can reserve that just for deterministic stuff. If you had a class that by contract only did nondeterministic generation, then there's still the friendly single-object OOP pattern.
That's a good point.
Today I learned that each ChaCha block the Linux RNG generates takes only 32 bits of input from things like RDRAND. I was hoping it was 128 bits. (RDRAND instructions usually pass through VMs to access the host's entropy. So if there were more bits poor VM entropy wouldn't matter.)
I assume that it reads more when it's initializing the pool, but I haven't gotten to that part yet.
01:00
Yeah, it's quite a bit to take in. I did take a look some time ago.
We really need a better language / environment to write an OS in, but nobody wants to start over :|
"We don't really know what the range of an int is at the time we're writing this code, but we promise we're not going out of that range" is scary enough. Pointers carrying almost no information in the compile time type system and no additional information at run time is scary enough, too.
(I know that there are #defined limits, but no one actually includes code that checks that the range is large enough. And I know there are explicitly sized types now, but short, int, and long are still ubiquitous.)
01:22
it seems the initial and final permutations of DES don't add any security at all, what's the rationale behind them?
@FutureSecurity Well, they are now discussing if they should demand that the 2-complement scheme must be used for C++. In a few hundred years, who knows, the language may actually adhere to the least surprise principles :P
To make hardware implementations simpler, I think. If you skipped those steps then you'd have to either make one round use a different setup from the rest or you'd have to conditionally apply the permutation. These were included in the design knowing that they don't affect security. (I don't know DES well at all, though.)
C is all about surprises though
Yeah, I did the software security thing from Maryland at Coursera. Interesting how easy it is to get into trouble.
Surprises for the programmer, surprises for the end user, and surprises for everyone doing business with an end user.
Everybody should get a bit of programming early in their education, say at 14. Then they understand why programs bug out now and then.
It's a wonder most work at all really.
I was asked if my security related program contained bugs. It was 10K lines of highly complex crypto code, without mathematical proof. So I answered: yes, let's hope that we covered the most important functionality with the test.
01:37
It would at least be nice for people not to think that computers are magic. Know that they do what they're told, not what you intend. Know "algorithms" are as fallible as humans because they depend on data or have inherent systematic properties. Know that AI really sucks but we're having good luck faking stuff with neural nets at the moment.
People thought/think that it was their iPhone that did the voice recognition. Not a server farm. They don't realize their audio leaves their phone. They don't realize that a human really is going to hear a fraction of what gets uploaded because that's how businesses "improve our services".
There's not intelligence or magic in those boxes we have. There are circuits, data, and liabilities.
So... the RNG doesn't pull in more than 32 bits per block from RDRAND, but every time the RNG is reseeded (every 5 minutes) it pulls in sufficient entropy.
I'll have to check how the entropy pool works now another time.
 
4 hours later…
05:46
@kelalaka The translation is right. In "the covent's hens brood" a) covent is a place, b) brood is a verb describing the hens action. In French, with present tense for multiple hens, both translate to "couvent" but these two identically spelled words have very different pronunciation.
In reading "les poules du couvent couvent" or "les poules couvent au couvent" (both triple checked for typo) you have to make reasoning on the tune of:
"couvent" is a noun or a verb, and only a noun or an adjective can follow "du" (introducing a possessor) or "au" (introducing a location).
Also, the heuristic that the verb "couvent" (brood) relates to "poule" (hens) helps. The phrase is somewhat harder to parse/spell with: "Elles couvent au couvent".
 
10 hours later…
16:04
Finally feel after working on this project for 8 years I have accomplished something. The problem is I am not a programmer, but I have a good understanding of binary.

I took 1 million random numbers from 0-1 generated in Excel. Ran them through the alg. process. Transferred them into word. In word I removed pronunciations such as spaces and carriage returns etc... produced a single line. Saved it in Word pag and then saved and zipped the file. Total file size for 1 million random digits......246,040 kb. Unzips lossless
Finally feel after working on this project for 8 years I have accomplished something. The problem is I am not a programmer, but I have a good understanding of binary.

I took 1 million random numbers from 0-9 generated in Excel. Ran them through the alg. process. Transferred them into word. In word I removed pronunciations such as spaces and carriage returns etc... produced a single line. Saved it in Word pag and then saved and zipped the file. Total file size for 1 million random digits......246,040 kb. Unzips lossless
 
2 hours later…
18:28
What's the accomplishment? You always wanted a zipped word document full of gibberish?
 
5 hours later…
23:20
@JonHutton Which one is it? The compression of 0-1 or 0-9? What where your goals of doing this?

« first day (3211 days earlier)      last day (1761 days later) »