[Cryptography-dev] Recipe for files?

[Stefan Pochmann]

Thanks everyone. I already considered using Fernet on file chunks, so I'm
glad to see that suggested. And yes, I love the Fernet spec (both content
and presentation) and I'll look into miniLock now.

My use case btw is encrypted cloud backup (for all my files). Everybody
seems to use their own formats and not describe them well and I couldn't
find a standard format, so I decided to try writing my own spec+tool. If I
succeed, I'll publish it and the spec shall be as nice as Fernet's. (I'm
under no illusion that it'll catch on, but I think it'll at least be fun
and useful for myself.)

Stefan


On Thu, Nov 20, 2014 at 6:48 PM, Glyph <glyph at twistedmatrix.com> wrote:

> Equally unfortunate:
>
> NotImplementedError: deadlock is Python 3 only, and is only known to run
> on 3.2 or above.
>
> -g
>
> On Nov 20, 2014, at 18:21, David Reid <dreid at dreid.org> wrote:
>
> Unrelated to PyCA there is at least one implementation of miniLock
> <https://github.com/kaepora/miniLock/blob/master/README.md> written in
> Python called deadlock <https://pypi.python.org/pypi/deadlock>, but it is
> unfortunately AGPLv3.
>
> -David
>
>
> On Thu, Nov 20, 2014 at 9:13 AM, Alex Gaynor <alex.gaynor at gmail.com>
> wrote:
>
>> One thing to think about is making sure your scheme isn't vulnerable to
>> truncation attacks.
>>
>> Alex
>>
>> On Thu Nov 20 2014 at 9:11:23 AM Paul Kehrer <paul.l.kehrer at gmail.com>
>> wrote:
>>
>>> Stefan,
>>>
>>> We’ve talked in the past about a recipe for file encryption. The general
>>> consensus has been that the project would prefer to implement an existing
>>> spec rather than creating one so for now I’m afraid creating your own is
>>> probably the “best” path unless you’re familiar with a standardized format
>>> that does this?
>>>
>>> If you do choose to implement your own I’d suggest implementing it on
>>> top of Fernet using a frame* size that you consider to be a good trade off
>>> between ciphertext length per frame and the size of the HMAC. Ideally a
>>> spec similar to https://github.com/fernet/spec could come out of it.
>>>
>>> -Paul Kehrer
>>>
>>> * I’ve been using frame when talking about this type of encryption to
>>> avoid confusing it with the native block size of a block cipher, but record
>>> (like a TLS record) would be equally descriptive.
>>>
>>> On November 20, 2014 at 6:27:07 AM, Stefan Pochmann (
>>> stefan.pochmann at gmail.com) wrote:
>>>
>>> I like the Fernet recipe, but I'd like a better recipe for files. One
>>> that doesn't want the entire message at once (bad for big files) and that
>>> doesn't bloat with base64. Should I do it myself with "hazardous materials"
>>> (I might adapt the Fernet code) or will you maybe add such a recipe soon?
>>>
>>> Something like this maybe:
>>>
>>>  f = SomethingLikeFernetButForFiles(key)
>>> for block in f.encrypt(filename, blocksize):
>>>     myhandling(block)
>>>
>>> Or with a handler parameter:
>>>
>>> f = SomethingLikeFernetButForFiles(key)
>>> f.encrypt(filename, blocksize, myhandling)
>>>
>>> Stefan
>>>  _______________________________________________
>>> Cryptography-dev mailing list
>>> Cryptography-dev at python.org
>>> https://mail.python.org/mailman/listinfo/cryptography-dev
>>>
>>> _______________________________________________
>>> Cryptography-dev mailing list
>>> Cryptography-dev at python.org
>>> https://mail.python.org/mailman/listinfo/cryptography-dev
>>>
>>
>> _______________________________________________
>> Cryptography-dev mailing list
>> Cryptography-dev at python.org
>> https://mail.python.org/mailman/listinfo/cryptography-dev
>>
>>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20141120/162f33fd/attachment.html>