Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87608
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <df1da8f007fc46dc8b2301b8930a3219@k-piste.dy.fi>
References: <CAKws9z1fatmSR2YLaeBn0zVv-s3iwCj7OUKjW949QC0L_VndpA@mail.gmail.com>
	<9996b5784a1bfbca80b07de01f1a7a94@k-piste.dy.fi>
	<CAKws9z3r6dQ1BQaA5Q9kQNpNu11M+EJ+LS7DwGZxajnfXmLYFg@mail.gmail.com>
	<df1da8f007fc46dc8b2301b8930a3219@k-piste.dy.fi>
Date: Tue, 4 Aug 2015 09:25:50 -0400
Message-ID: <CAAyV7nFHJs0JVzSEyFjhh49zFF=dD0q4_TxZTrbRLN+K4p4wLg@mail.gmail.com>
To: =?UTF-8?Q?Lauri_Kentt=C3=A4?= <lauri.kentta@gmail.com>
Cc: Scott Arciszewski <scott@paragonie.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP 7.1 Cryptography Projects
From: ircmaxell@gmail.com (Anthony Ferrara)

Lauri,

On Tue, Aug 4, 2015 at 9:12 AM, Lauri Kentt=C3=A4 <lauri.kentta@gmail.com> =
wrote:
> On 2015-08-04 14:54, Scott Arciszewski wrote:
>>
>> we do not allow secure modes
>
>
> I hope that was a typo... ;)

Indeed, it was not.

The concept for this (I've been working with Scott on it) is that this
should be a high-level abstraction. And any good high level
abstraction should make assumptions for its users. One of them is that
they want to be secure.

If you want to build an insecure cipher, the primitives will still
exist (openssl/etc).

> On 2015-08-04 14:54, Scott Arciszewski wrote:
>>
>> Version and configuration information (not what is passed, but what is
>> used) will be stored in the first few bytes of ciphertext output.
>
>
> Will this information be specific to the driver or to PCO, or is it possi=
ble
> to use other software for decryption? Will the API have a way to decrypt
> data based on that information (that is, without passing a DSN to the
> constructor)? How about producing a human-readable DSN of the relevant
> and/or all used settings to solve both of these cases?

Rather than human readable (since that would consume a lot of space in
the resulting ciphertext), I'd suggest a formalized open specification
of the storage formats. Similar to the headers used by TLS and other
formats. That way anyone can build to the specification, which would
be maintained along side the implementation.

So something like:

byte 0 : Version identifier

Version 1:
byte 1 : cipher identifier
byte 2 : mode identifier
byte 3 : authmode identifier
byte 4-8 : cipher-specific settings

At least that's my thoughts.

Anthony