ryuuchin

16 ms·

121.
by ryuuchin 10y ago
No, it really is that simple[1]. The only reason I can think of for someone not using uBlock Origin is because they've never heard of it. [1] https://github.com/gorhill/uBlock#performance
122.
by ryuuchin 10y ago
They could probably get away with keeping it but turning it into an off by default feature. Renaming the linker object file into telemetry.obj (or something entirely different) to enable it. It seems as though it wasn't really used t
123.
by ryuuchin 10y ago
> it's not clear to me that Firefox should want to isolate extensions from each other I think it's more interesting that the new(?) extension API (Jetpack) which was supposed to provide extension isolation is also apparently vu
124.
by ryuuchin 10y ago
Paper this article is based on can be found here[1]. I'm not aware that the tools they used or the source for the tools they used was ever released although it was reportedly given to the Mozilla reviewers[2]. Outside of the top 10 ex
125.
by ryuuchin 10y ago
I've been under the impression for a while now that unless you needed the super accurate timekeeping that ntpd provides (most don't) you're better off just using openntpd which should exist in most distro's repo's[1
126.
by ryuuchin 10y ago
Could they not have done something like how paxctl works on Linux? Such as globally enabling it but allowing for application specific control if you have to disable it (either through paxctl/xattr's or some policy file (rbac))? T
127.
by ryuuchin 10y ago
There is still a non-trivial privacy issue with the OCSP checks although OCSP stapling does address that problem. The Chrome situation does leave something to be desired although I can sort of understand where they were coming from from th
128.
by ryuuchin 10y ago
> Chrome's solution was to call OCSP useless because their less technical users couldn't understand it. OCSP introduced a non-trivial delay (cited as ~300ms to a second) and there are also privacy concerns with it as well[1].
129.
by ryuuchin 10y ago
> It wouldn't be even that much of a crime to use the same password on them, since there's virtually no way someone's going to pivot from a Fark account into my bank account. So quit being so dogmatic is what I'm sayi
130.
by ryuuchin 10y ago
> BoringSSL just uses /dev/urandom directly. Only if there's no hardware RNG support which I admit can happen (it's not perfect, I freely admit that). I suspect that for Google's use on their servers it's a
131.
by ryuuchin 10y ago
Perhaps in a really tight loop but the counter is still going to be several iterations ahead thanks to the out of order capabilities of the CPU. You may also have other things in play as well such as the micro-op cache depending on the cod
132.
by ryuuchin 10y ago
How much of an issue is this really though? Isn't the worst case a 1 cycle penalty for using a 32-bit int on x86-64 in the manner described in the article?
133.
by ryuuchin 10y ago
Just to mirror what's in the reddit thread the quick "fix" for this is to simply link to notelemetry.obj just as you would with the other small obj files included in the CRT lib directory[1]. Oddly notelemetry.obj is missing
134.
by ryuuchin 10y ago
What about a stream cipher like ChaCha20? Also would data-dependencies be different on a GPU than with parallelization on a CPU? Because modes like GCM (i.e. CTR) both the encryption and decryption are parallelizable (with CBC it's ju
135.
by ryuuchin 10y ago
> Microsoft changed their CSPRNG to FIPS 186-2 or NIST SP 800-90A It's changed once, in Vista SP1. Since then it's only used AES256 in CTR mode as a DRNG as specified in NIST 800-90. So I'm not sure it's fair to say
136.
by ryuuchin 10y ago
IMO they should make -d2SSAOptimizerUndefinedIntOverflow- a permanent option (i.e. not a hidden flag). I also think they should automatically enable it (that is, disable the optimizations) if the /sdl option is passed to the compiler
137.
by ryuuchin 10y ago
You can also use the hw rng if supported (e.g. rdrand) for fork/VM duplication safety. /dev/urandom should be fork safe though so long as you're not buffering data from it.
138.
by ryuuchin 10y ago
> trying to generate a large volume of random numbers in parallel on multiple cores You may be better off just using rdrand directly in this case depending on the throughput required. AFAIK you should be able to saturate all logical thr
139.
by ryuuchin 10y ago
I'm not sure. I think part of the problem is that Linux still uses entropy estimation. This is also one of the issues I have with the proposed replacement[1][2] for Linux's current CSPRNG implementation since it still retains en
140.
by ryuuchin 10y ago
As others have said it depends on your needs[6] and whether or not it has to be a CSPRNG (cryptographically secure). Since you mentioned OpenSSL I'll assume that in this context we are talking about a CSPRNG. The short answer is to ju
141.
by ryuuchin 10y ago
Obligatory "How To Safely Generate A Random Number" link[1] that I always wind up posting in threads like these. There's also the getrandom syscall[2] which uses the /dev/urandom pool. [1] http://sockpup
142.
by ryuuchin 10y ago
I'm not sure it's that simple. Someone mentioned a solution somewhere in this thread relating to if you're using udev. It still won't give you the block until seeded behavior but my post gave the solution to that (seed
143.
by ryuuchin 10y ago
Except it's easier to just use uBlock Origin for everything. The grid approach is far more intuitive than the text list you get with NoScript (IMO).
144.
by ryuuchin 10y ago
You can also specify the number of bytes you want with RtlGenRandom. rand_s only gives an unsigned int per call. Not a huge deal but you may be able to cut down on some function call overhead depending on how stuff gets inlined/optim
145.
by ryuuchin 10y ago
Because the DRNG (Digital RNG) on Intel processors filter the data through a DRNG (Deterministic RNG) (i.e. NIST 800-90)[1] which is constantly reseeded. The rdseed instruction was added later to allow for accessing the hardware generator
146.
by ryuuchin 10y ago
> Instead, using AES-128 CTR_DRBG Just for comparison this is what Windows does[1] for it's PRNG stuff (in Vista SP1 and newer at least). It uses AES256 in CTR mode as a DRNG[2]. [1] https://msdn.microsoft.com/en-u
147.
by ryuuchin 10y ago
RtlGenRandom[1] is probably the most convenient way on Windows. Does require certain definitions when including the header file for it[2] but otherwise does not require a CSP context and can generate any number of CSPRNG bytes. [1] https:
148.
by ryuuchin 10y ago
CryptGenRandom[1] or RtlGenRandom[2]. Although CryptGenRandom is the offical version they probably would rather you use I'm fairly certain that most people are more likely to use RtlGenRandom because it's accessing the same thing
149.
by ryuuchin 10y ago
It should probably just be using /dev/urandom in the first place.
150.
by ryuuchin 10y ago
The solution (currently sans kernel patching) is to just seed /dev/urandom yourself at system startup to avoid the issue of it not being seeded. Don't most distro's do this anyway? After that it's just down to usin

More ›