[design question] Symmetric cipher interface.

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[design question] Symmetric cipher interface.

Martin
In continuation of Dirk's Laurie proposal for standard interface for
common things...

How do you see generic interface for symmetric encryption/decryption?

Usually you can process input stream by parts (in case you wish to
encrypt 50GiB file which unlikely fit into string). Do you prefer
some functions encrypt()/decrypt() which returns output and inner
state, or object that holds inner state itself?

(There are a plenty of simple ciphers (Tea, Salsa, Spec) and I'd
wish to unite their implementations under common interface.)

-- Martin

Reply | Threaded
Open this post in threaded view
|

Re: [design question] Symmetric cipher interface.

Sean Conner
It was thus said that the Great Martin once stated:
> In continuation of Dirk's Laurie proposal for standard interface for
> common things...
>
> How do you see generic interface for symmetric encryption/decryption?
>
> Usually you can process input stream by parts (in case you wish to
> encrypt 50GiB file which unlikely fit into string). Do you prefer
> some functions encrypt()/decrypt() which returns output and inner
> state, or object that holds inner state itself?

  I prefer an object that holds inner state.  Tht way, I can have several
streams of input/output being encrypted/decrypted (say for a network
daemon).

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: [design question] Symmetric cipher interface.

Nagaev Boris
On Thu, Aug 17, 2017 at 1:59 PM, Sean Conner <[hidden email]> wrote:

> It was thus said that the Great Martin once stated:
>> In continuation of Dirk's Laurie proposal for standard interface for
>> common things...
>>
>> How do you see generic interface for symmetric encryption/decryption?
>>
>> Usually you can process input stream by parts (in case you wish to
>> encrypt 50GiB file which unlikely fit into string). Do you prefer
>> some functions encrypt()/decrypt() which returns output and inner
>> state, or object that holds inner state itself?
>
>   I prefer an object that holds inner state.  Tht way, I can have several
> streams of input/output being encrypted/decrypted (say for a network
> daemon).
>
>   -spc
>

I like the way the symmetric cryptography primitives are abstracted in Go:

Block cipher: https://golang.org/pkg/crypto/cipher/#Block
Authenticated encryption with associated data:
https://golang.org/pkg/crypto/cipher/#AEAD

--
Best regards,
Boris Nagaev

Reply | Threaded
Open this post in threaded view
|

Re: [design question] Symmetric cipher interface.

Gé Weijers
In reply to this post by Martin
For inspiration take a look at libsodium or NaCL: https://en.wikipedia.org/wiki/NaCl_(software)

These interfaces are simple, and much harder to misuse than most. They're not much use for encrypting a long stream, but doing that correctly is pretty difficult.


On Thu, Aug 17, 2017 at 10:44 AM, Martin <[hidden email]> wrote:
In continuation of Dirk's Laurie proposal for standard interface for
common things...

How do you see generic interface for symmetric encryption/decryption?

Usually you can process input stream by parts (in case you wish to
encrypt 50GiB file which unlikely fit into string). Do you prefer
some functions encrypt()/decrypt() which returns output and inner
state, or object that holds inner state itself?

(There are a plenty of simple ciphers (Tea, Salsa, Spec) and I'd
wish to unite their implementations under common interface.)

-- Martin




--
--

Reply | Threaded
Open this post in threaded view
|

Re: [design question] Symmetric cipher interface.

Martin


On 08/24/2017 03:15 PM, Gé Weijers wrote:

> For inspiration take a look at libsodium or NaCL:
> https://en.wikipedia.org/wiki/NaCl_(software)
> <https://en.wikipedia.org/wiki/NaCl_%28software%29>
>
> These interfaces are simple, and much harder to misuse than most.
> They're not much use for encrypting a long stream, but doing that
> correctly is pretty difficult.
>
>
> On Thu, Aug 17, 2017 at 10:44 AM, Martin <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     In continuation of Dirk's Laurie proposal for standard interface for
>     common things...
>
>     How do you see generic interface for symmetric encryption/decryption?
>
>     Usually you can process input stream by parts (in case you wish to
>     encrypt 50GiB file which unlikely fit into string). Do you prefer
>     some functions encrypt()/decrypt() which returns output and inner
>     state, or object that holds inner state itself?
>
>     (There are a plenty of simple ciphers (Tea, Salsa, Spec) and I'd
>     wish to unite their implementations under common interface.)
>
>     -- Martin
>
> --
> Gé

Thank you for link. I've viewed interfaces and most liked that for TCL,
(not posting link, or mail daemon consider this message as spam).

--[[
Even nowdays many people that says things like "our passwords are
encrypted with MD5!" don't understand crypto primitives. So misuse-proof
interface is essential.

Many crypto algorithms have subtle variants, easy to misuse (SHA-256 or
SHA-512/256?). For most of them variants with custom initialization
vectors, constants, number of rounds may be done. Such flexibility
easy to implement but hard to use.

For easy use some reduced interface is needed. And there are at least
two marginal approaches: functional and object-oriented. With functions
callers code doesn't need to do initialization work (fire and forget).
With object-oriented complex things are possible (like by-chunk
encryption in coroutine).

So general question was which of these extreme snippets is better:

  local inner, state, plus, result = encrypt(input, some, magic, params)

or

  local cryptor = c_cryptor:new()
  cryptor.some = magic
  cryptor.inner = params
  cryptor.input = chunk
  cryptor:run()
  local result = cryptor.output

Looks like OO-variant is more practical due native possibility to store
inner state inside.
]]

-- Martin