From owner-svn-src-head@freebsd.org Sun Apr 16 14:26:50 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23263D4057B; Sun, 16 Apr 2017 14:26:50 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-wr0-f173.google.com (mail-wr0-f173.google.com [209.85.128.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B594FF0D; Sun, 16 Apr 2017 14:26:49 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-wr0-f173.google.com with SMTP id l28so71895257wre.0; Sun, 16 Apr 2017 07:26:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=9Ksgs0OygMb9MAZWTbagFj2BzrQnVpA+xvHyOyzBviM=; b=NhYrMFc2+6XwwsXbpVzmcYL1mGKBlUfgIAS5qOQh9LRq7E7W6k1yZd2V96Nt6Rqc/N kNwEDYa6+vryIyS1cAZlGpHwuYy7U76Jb/4U8uDx17wKhEu/Z65+MQ7+yuhyNThge0ez /ytVFY1S/gTjxCb6ih02KnkaNC0Rn3CdyMSkpBdFUpLFXJI0w3xBZ3H6JW6YEb7G4xej Q0GSyE/iZZGNdbU1YzuGy88h7a6DkV/PiYO+v1FtdAL9UgbGSXogsf9+XIuNIZvipnWK 1/6dr9wUwIw+yoDbjwV3rjk9M8D4qIQKIAHuQcbqSoUfxQxKNPSkHfxyml09xqSbmh1d rxCA== X-Gm-Message-State: AN3rC/7fDa17tmSE4HJxwBkfttydgZXXtF+5zwTRqmByPe8fpOTwYyyA kb7K+f2lZu1zmPC3RsM= X-Received: by 10.223.153.18 with SMTP id x18mr14748368wrb.55.1492352802123; Sun, 16 Apr 2017 07:26:42 -0700 (PDT) Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com. [74.125.82.52]) by smtp.gmail.com with ESMTPSA id a10sm10480363wra.17.2017.04.16.07.26.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Apr 2017 07:26:42 -0700 (PDT) Received: by mail-wm0-f52.google.com with SMTP id t189so19729795wmt.1; Sun, 16 Apr 2017 07:26:42 -0700 (PDT) X-Received: by 10.28.130.210 with SMTP id e201mr5558461wmd.128.1492352801866; Sun, 16 Apr 2017 07:26:41 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.80.169.4 with HTTP; Sun, 16 Apr 2017 07:26:41 -0700 (PDT) In-Reply-To: References: <201704160911.v3G9B3df023095@repo.freebsd.org> From: Conrad Meyer Date: Sun, 16 Apr 2017 07:26:41 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r317015 - in head/sys: boot/forth conf crypto/chacha20 dev/random libkern sys To: Mark R V Murray Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2017 14:26:50 -0000 On Sun, Apr 16, 2017 at 2:19 AM, Mark R V Murray wrote: > This does not use DES' Chacha20 commit, as I had already completed the > testing for it, and received SO@ approval. > > DES's commit made Chaha20 a module. This is of no use to arc4random(9), > which needs the code to be standard. Also his API is different. > > I have no objection to reworking the arc4random/Chacha below to use DES' > version of Chacha, but his code needs to be standard library code, > not an optional module. > > Any objections to me doing this? Hi Mark, I think you've taken the only sane approach possible here. arc4random cannot be loadable, and it needs a standard cipher. RC4 is undesirable because large parts of its early keystream are predictable and it is anticipated to have other weaknesses. I doubt Chacha comes out to much in the way of object code, and removing RC4 should subsidize even that number. From AMD64: chacha20.ko is 7 kB. Furthermore, I do not believe you should be harangued into rewriting how RNG use works in the kernel just to allow Chacha to be loadable. And if it is "loadable," so what? You can't boot without it; what good does a mandatory loadable module do? So: * I believe you've taken the right approach. But somehow your import of chacha should be reconciled with DES' import (i.e., keep only one copy in the tree). * I don't believe the chacha code being standard is an undue burden. Especially balanced by kicking out RC4. Thanks for doing this work. Best, Conrad