Re: arc4random weakness

Steven Chamberlain wrote: > Please consider switching to ChaCha20 in the long term (kern/182610), > but right now, at least increase the amount of early keystream that is > discarded. Many, many thanks delphij+so for applying the latter change so quickly! Also it is great to see INHERIT

Re: arc4random weakness (was: WikiLeaks CIA Exploits: FreeBSD References Within)

ems 4-5 years old already as it prohibits use of RC4 at all from 2014 onward. Please consider switching to ChaCha20 in the long term (kern/182610), but right now, at least increase the amount of early keystream that is discarded. Many thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org diff

Re: FreeBSD Security Advisory FreeBSD-SA-14:19.tcp

is able to do that so easily. Whereas, the attack described in this advisory could work blindly against two remote endpoints. I believe I understand now. Regards, -- Steven Chamberlain ste...@pyro.eu.org ___ freebsd-security@freebsd.org mai

Re: FreeBSD Security Advisory FreeBSD-SA-14:19.tcp

x27;t the same be done with a single RST packet? Thanks Regards, -- Steven Chamberlain ste...@pyro.eu.org ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to &qu

Re: Speed and security of /dev/urandom

about draining entropy too quickly from the CSPRNG, a non-privileged user could do that anyway from /dev/urandom, or it may happen when a server doing crypto work is under stress? Regards, -- Steven Chamberlain ste...@pyro.eu.org ___ freebsd-security@fre

Re: Speed and security of /dev/urandom

ut, and perhaps be already as fast as doing getpid on each call and running a stream cipher in userland. RW mentioned kernels without RANDOM, being an awkward situation for which it seems necessary to fall back to the PRNG in userland. Regards, -- Ste

Re: Speed and security of /dev/urandom

to seed the arc4random in userland (with ~256 bytes or so), it would be just like OpenBSD getentropy(2)? Just yesterday, something very similar is proposed for Linux, called getrandom(2): http://lists.openwall.net/linux-kernel/2014/07/18/329 Regards, -- Steven Chamberlain ste...@pyro.eu.org s

Re: Speed and security of /dev/urandom

the pool is low. Applications have been encouraged to not excessively read even from /dev/urandom, for the same reason, so it makes sense on Linux to stretch with RC4 or something. Regards, -- Steven Chamberlain ste...@pyro.eu.org ___ freebsd-security@

Re: Speed and security of /dev/urandom

made, even if it seems obvious. > will have exactly the > same initial state if there is no provision to reseed the PRNG. There is arc4random_stir, but an application could easily forget to do that. Users of libevent for example, which uses arc4random, doesn't expose an API function

Speed and security of /dev/urandom

also the benefit that having many readers from a single pseudorandom stream, adds an additional kind of randomness to its output). This is obviously a complex issue, and some of it will be subjective. But I welcome your comments. Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org

Re: Update for FreeBSD Security Advisory FreeBSD-SA-12:04.sysret for 8.1

t of the function, including userret(); would that have consequences? Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any

SA-12:04 commit on RELENG_8_1 incorrect?

and the code inserted looks like it wouldn't be effective: http://svnweb.freebsd.org/base/releng/8.1/sys/amd64/amd64/trap.c?revision=236953&view=markup#l965 Please could someone take a look at this and let me know if it was really intended. Thanks! Regards, -- Steven Chamberlain ste..