From owner-freebsd-security@FreeBSD.ORG Sat Jul 19 21:02:20 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2495DB for ; Sat, 19 Jul 2014 21:02:19 +0000 (UTC) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8FA962E88 for ; Sat, 19 Jul 2014 21:02:19 +0000 (UTC) X-AuditID: 1209190c-f79ef6d000005dd6-fa-53cadcd4f351 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id C9.00.24022.4DCDAC35; Sat, 19 Jul 2014 17:02:12 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s6JL2BS0029443; Sat, 19 Jul 2014 17:02:12 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6JL2Anv024520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 19 Jul 2014 17:02:11 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6JL29qC012183; Sat, 19 Jul 2014 17:02:09 -0400 (EDT) Date: Sat, 19 Jul 2014 17:02:09 -0400 (EDT) From: Benjamin Kaduk To: Konstantin Belousov Subject: Re: Speed and security of /dev/urandom In-Reply-To: <20140719205350.GX93733@kib.kiev.ua> Message-ID: References: <53C85F42.1000704@pyro.eu.org> <20140719190348.GM45513@funkthat.com> <20140719192605.GV93733@kib.kiev.ua> <53CAD950.1010609@pyro.eu.org> <20140719205350.GX93733@kib.kiev.ua> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nrnvlzqlgg02dahY9m56wWTRMe8zm wOQx49N8Fo+ds+6yBzBFcdmkpOZklqUW6dslcGVsOraFteAeT8Xv3RkNjPO4uhg5OSQETCSO 7znICGGLSVy4t56ti5GLQ0hgNpNE6/1WVghnI6PEmReLGCGcQ0wSE468ZYJwGhglVi9YwgLS zyKgLTHp2xUmEJtNQEVi5puNbCC2iICuxMcFe5hBbGYBBYn3j08C1XBwCAvoS2w+JA1icgoY Sjx8LAxSwSvgKLFqzhVWEFtIYCejxK9HYLaogI7E6v1TWCBqBCVOznzCAjHRUuLcn+tsExgF ZyFJzUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXUC83s0QvNaV0EyMoTDkleXYwvjmo dIhRgINRiYf3xelTwUKsiWXFlbmHGCU5mJREeW0OAIX4kvJTKjMSizPii0pzUosPMUpwMCuJ 8P5oAcrxpiRWVqUW5cOkpDlYlMR531pbBQsJpCeWpGanphakFsFkZTg4lCR4l90GahQsSk1P rUjLzClBSDNxcIIM5wEavg6khre4IDG3ODMdIn+KUVFKnPfaLaCEAEgiozQPrheWRl4xigO9 IsxrB9LOA0xBcN2vgAYzAQ2WLj8OMrgkESEl1cA494Rv/dt1toUN93ttS1SLlLbcj3uTLRxr lt/9u+Pz90aemZdYrxS6tIgZ7uKS/bhFJObIqvbN/rwmtY05Ak/+y8txnrrxe+Kzaocmkd4H ywX7Tkz+fGXVzW/XV/65odv/ib1PSu76yq425QvcvP43Ouw3r3R/LLhiCmPNMTHB5w4bJ4sc 2taqxFKckWioxVxUnAgAZVoEwf4CAAA= Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 21:02:20 -0000 On Sat, 19 Jul 2014, Konstantin Belousov wrote: > On Sat, Jul 19, 2014 at 09:47:12PM +0100, Steven Chamberlain wrote: >> On 19/07/14 20:26, Konstantin Belousov wrote: >>> I think that using sysctl for non-management functionality is wrong. >>> If this feature is for the libraries and applications, and not for >>> system management and introspection utilities, it should be normal >>> syscall. >> >> If this is only 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 > > We, in fact, do not use sysctl for seeding SSP canary. Kernel puts > random bytes on stack, and libc fetches them. But it is 64 bytes for > 64-bit platforms, 32 bytes for 32-bit. > > Yes, the interface of the getrandom(2) from the link above looks > reasonable. The big question is, indeed, about its supposed use I thought so, too, when I read it. > models. For one-time seeding of RNG with fixed amount of bytes, > the ELF aux vector mechanism is much less intrusive and faster. I think there is a lot of value in providing a syscall interface which can be the default way for applications to retrieve random bits. This would avoid any issues with needing to track fork() and such, eliminating many sources of worry. Performance-sensitive applications which do not want to suffer such syscall overhead may implement other PRNGs, and may be assumed to be somewhat aware of what they are doing. -Ben