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

[Dewayne Geraghty]

On 14 March 2017 at 09:06, Steven Chamberlain  wrote:

> From this document (TOP SECRET//SI//NOFORN):
> https://wikileaks.org/ciav7p1/cms/files/NOD%20Cryptographic%
> 20Requirements%20v1.1%20TOP%20SECRET.pdf
>
> version 1.0 said:
>
> | 8. (S//NF) [...] If RC4 is used, at least the first 1024
> | bytes of the cryptostream must be discarded and may not be used
>
> and that is exactly what FreeBSD's libc and in-kernel arc4random
> implementations do.
>
> version 1.1 received input from another agency:
>
> | (C//SI//REL FVEY) Coordinated with NSA/CES.
>
> and a new requirement was introduced:
>
> | (TS//SI) 5.9: Added additional information about proper use of RC4.
>
> | 9. (TS//SI) Further than stated above, if RC4 is used the first 3072
> | bytes of the cryptostream must be discarded and may not be used.
>
> I think you should take that to mean, the NSA has, or suspects someone
> else to have, a practical attack on RC4 when being used as FreeBSD does
> currently.  The document seems 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
>

Thanks Steven.  I wasn't aware that OpenBSD was 3.5+ years ahead of the
curve in terms of securing against RC4 weaknesses, compared to FreeBSD.
Perhaps they have access to a mole ;)

The pointer to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=182610
probably needs a push along. (or a local patch, which mostly applied to
/usr/src/lib/libc/gen/arc4random.c ; 2 of 13 hunks need a manual adjustment)
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

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

[Steven Chamberlain]

From this document (TOP SECRET//SI//NOFORN):
https://wikileaks.org/ciav7p1/cms/files/NOD%20Cryptographic%20Requirements%20v1.1%20TOP%20SECRET.pdf

version 1.0 said:

| 8. (S//NF) [...] If RC4 is used, at least the first 1024
| bytes of the cryptostream must be discarded and may not be used

and that is exactly what FreeBSD's libc and in-kernel arc4random
implementations do.

version 1.1 received input from another agency:

| (C//SI//REL FVEY) Coordinated with NSA/CES.

and a new requirement was introduced:

| (TS//SI) 5.9: Added additional information about proper use of RC4.

| 9. (TS//SI) Further than stated above, if RC4 is used the first 3072
| bytes of the cryptostream must be discarded and may not be used.

I think you should take that to mean, the NSA has, or suspects someone
else to have, a practical attack on RC4 when being used as FreeBSD does
currently.  The document seems 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 -Nru a/head/lib/libc/gen/arc4random.c b/head/lib/libc/gen/arc4random.c
--- a/head/lib/libc/gen/arc4random.c	2016-10-12 14:56:14.834409000 +0100
+++ b/head/lib/libc/gen/arc4random.c	2017-03-13 21:57:16.532833171 +
@@ -160,7 +160,7 @@
 	 * Discard early keystream, as per recommendations in:
 	 * "(Not So) Random Shuffles of RC4" by Ilya Mironov.
 	 */
-	for (i = 0; i < 1024; i++)
+	for (i = 0; i < 3072; i++)
 		(void)arc4_getbyte();
 	arc4_count = 160;
 }
diff -Nru a/head/sys/libkern/arc4random.c b/head/sys/libkern/arc4random.c
--- a/head/sys/libkern/arc4random.c	2016-11-25 17:20:23.862538000 +
+++ b/head/sys/libkern/arc4random.c	2017-03-13 21:58:45.985402563 +
@@ -84,11 +84,11 @@
 	/*
 	 * Throw away the first N words of output, as suggested in the
 	 * paper "Weaknesses in the Key Scheduling Algorithm of RC4"
-	 * by Fluher, Mantin, and Shamir.  (N = 256 in our case.)
+	 * by Fluher, Mantin, and Shamir.  (N = 768 in our case.)
 	 *
 	 * http://dl.acm.org/citation.cfm?id=646557.694759
 	 */
-	for (n = 0; n < 256*4; n++)
+	for (n = 0; n < 768*4; n++)
 		arc4_randbyte(arc4);
 
 	mtx_unlock(>mtx);


signature.asc
Description: Digital signature