linux-kernel - Re: [2.6 patch] let CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 14 Jul 2006 22:55:28 -0400
From:	Valdis.Kletnieks@...edu
To:	andrea@...share.com
Cc:	Pavel Machek <pavel@...e.cz>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	ajwade@...001346162bf9-cm0011ae8cd564.cpe.net.cable.rogers.com,
	Lee Revell <rlrevell@...-job.com>,
	"Randy.Dunlap" <rdunlap@...otime.net>,
	Andrew Morton <akpm@...l.org>, bunk@...sta.de,
	linux-kernel@...r.kernel.org, mingo@...e.hu
Subject: Re: [2.6 patch] let CONFIG_SECCOMP default to n

On Fri, 14 Jul 2006 01:11:18 +0200, andrea@...share.com said:
> On Thu, Jul 13, 2006 at 09:29:41PM +0000, Pavel Machek wrote:
> > Actually random delays are unlike to help (much). You have just added
> > noise, but you can still decode original signal...
> 
> You're wrong, the random delays added to every packet will definitely
> wipe out any signal.

I call shenanigans on that.

Take a look at the NTP userspace code, which has some very nice code to
filter network jitter. 

In fact, the best you can do here is to reduce the effective bandwidth
the signal can have, as Shannon showed quite clearly.

And even 20 years ago, the guys who did the original DoD Orange Book
requirements understood this - they didn't make a requirement that covert
channels (both timing and other) be totally closed down, they only made
a requirement that for higher security configurations the bandwidth of
the channel be reduced below a specified level...

Content of type "application/pgp-signature" skipped