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-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 16 Jul 2006 03:54:27 +0200
From:	Pavel Machek <pavel@...e.cz>
To:	andrea@...share.com
Cc:	Valdis.Kletnieks@...edu, 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, Jul 14, 2006 at 10:55:28PM -0400, Valdis.Kletnieks@...edu wrote:
> > In fact, the best you can do here is to reduce the effective bandwidth
> > the signal can have, as Shannon showed quite clearly.
> 
> Yes.
> 
> > 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...
> 
> Why I think it's trivial to guarantee the closure of the seccomp side
> channel timing attack even on a very fast internet by simply
> introducing the random delay, is that below a certain sampling
> frequency you won't be able to extract data from the latencies of the
> cache. The max length of the random noise has to be >= of what it
> takes to refill the whole cache. Then you won't know if it was a
> cache

You won't know for sure... but. Let t be time takes to reload the
cache. Let your random noise be in <0, t> interval. According to you,
that would be okay. IT IS NOT.

If the original delay was long, and your generator returned t,
attacker sees 2*t. He can be _sure_ delay was long now.

If the delay was short, and your generator returns 0, attacker sees 0,
and _knows_ delay was short. (Chance that generator produces 0 or t is
small, but non zero).

Even if you do random noise in <0, 2*t) interval, I'll be able to
gather some statistics.

							Pavel
Thanks, Sharp!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists