Hi Todd,
We're not going to merge non-standard extensions to Fernet. You're welcome
to attempt to contribute to the upstream spec, but absent a change there
I'm going to close your PR.
Alex
On Wed, Jun 1, 2016 at 12:44 PM, Todd Knarr wrote:
> On 05/30/2016 08:49 PM, Todd Knarr wrote:
>
>> It's
On 05/30/2016 08:49 PM, Todd Knarr wrote:
It's also available as a pull request on Github.
Pull request 2938:
https://github.com/pyca/cryptography/pull/2938
Looks to be passing tests at this point, it's still waiting for Jenkins
to report in.
smime.p7s
Description: S/MIME Cryptographic Sign
On 05/28/2016 07:51 AM, Cory Benfield wrote:
Unfortunately, Fernet is implemented by more than just the Python
cryptography project, and *those* implementations may not react as
well to higher-key-length AES encryption mechanisms.
Would the attached be an acceptable change? The Fernet class cont
> On 27 May 2016, at 22:17, Todd Knarr wrote:
>
> On 05/27/2016 09:27 PM, Alex Gaynor wrote:
>> The problem is Fernet refers to a specific standard, if you change it,
>> you've got something new and not interoperable :-)
> Oddly, it would interoperate (at least using cryptography's implementati
On 05/27/2016 09:27 PM, Alex Gaynor wrote:
The problem is Fernet refers to a specific standard, if you change it,
you've got something new and not interoperable :-)
Oddly, it /would/ interoperate (at least using cryptography's
implementation) if you used the correct-sized key for the AES encrypt
The problem is Fernet refers to a specific standard, if you change it,
you've got something new and not interoperable :-)
Alex
On Sat, May 28, 2016 at 12:25 AM, Todd Knarr wrote:
> On 05/27/2016 07:36 PM, Alex Gaynor wrote:
>
>> Fernet is a standard maintained outside pyca/cryptography, we woul
On 05/27/2016 07:36 PM, Alex Gaynor wrote:
Fernet is a standard maintained outside pyca/cryptography, we wouldn't
implement anything in Fernet that wasn't a part of that standard.
How about a version that left the Fernet class itself using AES128 but
added new classes that'd use AES192 and AES25
Fernet is a standard maintained outside pyca/cryptography, we wouldn't
implement anything in Fernet that wasn't a part of that standard.
The standard itself is in something of a hybernation state ATM, so candidly
I don't know how receptive they'd be to such a proposed change.
I fear your best opt
Would there be an interest in, or philosophical/design objections to, a
patch to allow Fernet to use AES192 and AES256 encryption? I've got a
situation where Fernet would be a good fit but 256-bit encryption is
highly desired.
smime.p7s
Description: S/MIME Cryptographic Signature
__
