Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93802 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64153 invoked from network); 5 Jun 2016 08:23:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Jun 2016 08:23:41 -0000 Authentication-Results: pb1.pair.com header.from=scott@paragonie.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=scott@paragonie.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain paragonie.com designates 209.85.218.49 as permitted sender) X-PHP-List-Original-Sender: scott@paragonie.com X-Host-Fingerprint: 209.85.218.49 mail-oi0-f49.google.com Received: from [209.85.218.49] ([209.85.218.49:36598] helo=mail-oi0-f49.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A7/B1-55579-B81E3575 for ; Sun, 05 Jun 2016 04:23:41 -0400 Received: by mail-oi0-f49.google.com with SMTP id j1so185710207oih.3 for ; Sun, 05 Jun 2016 01:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paragonie-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=v1kr9xdEUnR7l0NgAWj0MOOF/Y/NLgkf9PUeJYZbR0Q=; b=sz9MJAAUaYZup16dGnhdk9Kdvy+gTCjPmPyKOKzl+7jJb2eL7zCfQC37Rex0NH5rWV a2xE156zbCAh8RqhV6FNmL+RJGUmDI0I6OK0djRG6FguqZKoFE4KuV02EWi8GecNJNPE oW2X1RGdqr0Ckduh4BpRMc6HjkjEEyerIn5VCgl9siaAiQVdkGNuW45qoYVD4Ji2d4id ektogF7+uyB9uO7L9RNowtuucXmcTXS+n+JFBdoZVl5XDQxvLFHrV3uGnsy5UplfRFYK wrt2jjOYdJP5s7eVquH4eCLPspxpkE8fnGABlxj7u6cSb2F9VphSb6WKsFXGWbP3epV7 ql3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=v1kr9xdEUnR7l0NgAWj0MOOF/Y/NLgkf9PUeJYZbR0Q=; b=aDaqHiM8k5AoaEtX4E3ezyvmsItMsRdvTjoTlIWf33m398fMiM2s8XnTM9ALN6xZgA RFX4qYATN+7pgJJfa0nF/uKW0zsKi6ouHscJnXCgAPmyLNA3+XFPuH9H4PXKx6P0FLFB Pn3CMhPzzhgdPcgpaEo6bcCKyGB8c8Q5iZZglTeBlNtBIYkNI5N/5s8LYged9LO3kHKg pP96i0tJ74JDXewrZHh3RbX6no0iSONL24eFlUQLqGfF0x6/89hSF/mlooa28qaXW5g9 lMwilkZvKOWI2+66veOQPnh/YKYrWDvQeBbksdMQS2zkxoFQLQH1aU3BOrgYSbitqGzW 65Xg== X-Gm-Message-State: ALyK8tL5CTaXeYYeFIyGCku80Bu1d6gBoglo3xPyHeY2E9U4BBejxnzIlwT0K48dChT66Beu1c/6IGamfcnU3Q== MIME-Version: 1.0 X-Received: by 10.202.186.193 with SMTP id k184mr6234159oif.66.1465115016368; Sun, 05 Jun 2016 01:23:36 -0700 (PDT) Received: by 10.157.26.106 with HTTP; Sun, 5 Jun 2016 01:23:36 -0700 (PDT) In-Reply-To: <8ebf9e48-62e5-fae5-d234-448be3c1f9d2@fleshgrinder.com> References: <8ebf9e48-62e5-fae5-d234-448be3c1f9d2@fleshgrinder.com> Date: Sun, 5 Jun 2016 04:23:36 -0400 Message-ID: To: PHP Internals Cc: Pierre Joye , Stas Malyshev Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] [RFC] Libsodium - Discussion From: scott@paragonie.com (Scott Arciszewski) On Sun, Jun 5, 2016 at 4:12 AM, Fleshgrinder wrote: > On 6/5/2016 9:46 AM, Scott Arciszewski wrote: >> Libsodium already knocks it out of the park compared to OpenSSL and >> Mcrypt. If we want to talk about a higher-level abstraction-- such as >> what's provided by paragonie/EasyRSA + defuse/php-encryption or >> paragonie/halite-- I wholeheartedly endorse that discussion. But I don't >> think we should try to solve that problem with this particular RFC. >> >> In closing, I don't disagree that a simple crypto API is a good goal to >> have. I just think the ideal you're discussing is: >> >> A. Out of scope, and >> B. Kind of belittling to how much of an improvement libsodium is to what we >> already have. >> > > You are completely ignoring that once this is out the door there is no > way back. We already see many problems in the current API and we should > address them until we reach a point where the majority does not see > major problems anymore. > > Doing anything else is just irresponsible! > > -- > Richard "Fleshgrinder" Fussenegger > I'm trying to keep concerns separate. I do want to make the pluggable crypto API happen, but I barely have time for this libsodium RFC and I don't want to conflate the two. (Even worse: I wouldn't want the mere thought of an abstract high-level API to block libsodium from getting accepted.) Instead of /completely redesigning/ the libsodium API, what are some changes that need to be made to alleviate the majority of concerns ("it's not the pluggable crypto API" notwithstanding)? Two things to keep in mind: 1. If it breaks existing code that uses libsodium-php in a nontrivial way, I'm going to resist the change unless it can be proven necessary for the sake of everyone's sanity. 2. If it greatly deviates from the experience of using libsodium in other programming languages (e.g. renaming crypto_box), you no longer have libsodium and thus I will resist it. Getting rid of redundant features (by improving existing ones, not just cutting them!) is fine. Dropping scrypt, etc. is fine. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises