[OTR-dev] Issues with libgcrypt 1.5

[Werner Koch]

On Mon, 11 Apr 2011 13:48, ian at cypherpunks.ca said:

> In 1.4, if the plaintext was not a multiple of the block size, the last
> encrypted counter block was simply truncated to the appropriate length,
> which seems like the correct behaviour to me.  (And indeed, is what the
> libotr library expects.)

Okay, I'll revert that.

> Ideally, CTR mode would operate like a stream cipher whose keystream was
> E(c) || E(c+1) || E(c+2) || ... .  That would mean stashing away the
> "truncated" part above for use at the start of the next encryption.
> I don't know whether 1.4 did that or not; I didn't try encrypting twice

No it did not.  However we(?) once talked about this and my idea was to
add a blocking layer to avoid doing that explicitly for each mode.  This
would also allow to disable this blocking layer to get better
performance.  The problem with not requiring full blocks in CBC etc, is
that we can't used aligned versions of the encryption functions, need to
shift the data in memory and save parts of the input.  A flag to
explicitly enable arbitrary lengths input is IMHO the cleanest solution.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.