accessing arcfour sboxes

[Simon Josefsson]

Moritz Schulte <mo@g10code.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> I tried to implement this in libgcrypt, and noticed the
>> cipher-specific _ctl functions has been removed,
>
> Sorry, about exactly which functions are you talking here?

I was wrong, I had been thinking about the gcry_md_info() function in
the old API, which I probably never understood.

So it appears the framework I wanted to use was never implemented, and
in that case I understand Werner's opinion that it complicate matters
for a small gain.

>> (btw, why does a stream cipher need different encryption/decryption
>> calls?).
>
> Hmm, well, the encrypt/decrypt functions of a stream cipher need an
> argument that specify the amount of bytes provided, don't they?

Yes, but encryption and decryption is the same operation for a stream
cipher; "pt XOR stream" vs "ct XOR stream".  But this doesn't matter,
really.

>> /* Perform various operations on the cipher object H. */
>> gcry_error_t gcry_cipher_ctl (gcry_cipher_hd_t h, int cmd, void *buffer,
>> 			     size_t buflen);
>
> I just wonder wether this would be the best interface.  How exactly
> would you like to call this function?  I mean, you somehow have to
> pack the data (the S-Box array and two numbers) into a `buffer' and
> arcfour.c would have to access this buffer the same way.
>
> I have something like this in mind:
>
> Let Libgcrypt export:
>
>   typedef enum gcry_ctl
>   {
>     GCRY_CTL_ARCFOUR_CONTEXT_SET,
>     GCRY_CTL_ARCFOUR_CONTEXT_GET
>   } gcry_ctl_t;
>
>   typedef struct gcry_arcfour_context
>   {
>     int i, j;
>     byte sbox[256];
>   } gcry_arcfour_context_t;
>
>   gcry_error_t gcry_cipher_control (gcry_cipher_hd_t handle,
>                                     gcry_ctl_t action,
>                                     void *data);
>
> Then the caller could do:
>
>   gcry_arcfour_context_t c = { ... };
>   err = gcry_cipher_control (handle,
>                              GCRY_CTL_ARCFOUR_CONTEXT_SET, &c);

Yes, this was exactly what I had in mind!  Thanks for understanding my
poor explanation.

> Extending other ciphers this way would mean, one would have to:
>
>   * add new `actions' to the gcry_ctl_t list,
>   * define according types for casting to/from the `void *data'
>     argument

Yes.

Thanks,
Simon