[Cryptography] Direct public confirmation from Dr. Rogaway

[Phillip Hallam-Baker]

On Sat, Feb 27, 2021 at 9:34 PM Salz, Rich via cryptography <
cryptography at metzdowd.com> wrote:

> https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/ :
>
>
>
> I can confirm that I have abandoned all OCB patents
>
> and placed into the public domain all OCB-related IP of mine.
>
> While I have been telling people this for quite some time, I don't
>
> think I ever made a proper announcement to the CFRG or on the
>
> OCB webpage. Consider that done.
>
>
>
> I hope people will use the scheme to do positive things.
>

Looks to me like it could be reasonably easy to convert the existing .NET
crypto provider to support this mode by piggybacking on the existing ECB
mode. The reason I want to build on .NET rather than roll my own AES is I
want to get the benefit of any hardware acceleration that may be available
on a given platform. Microsoft is far more likely to do this than I am. And
if I do, I will want to have the benefit for all AES related crypto, not
just OCB.

The heart of the API is ICryptoTransform.TransformBlock:

public int TransformBlock (byte[] inputBuffer, int inputOffset, int
inputCount, byte[] outputBuffer, int outputOffset);

Transform Block is ALWAYS called on an even block boundary but it can be
called on multiple blocks. It is called sequentially so it doesn't allow
direct use to be made of the parallel capabilities of OCB.


So I can create a wrapper around an ECB mode cipher:

0) create a buffer that is at least as large as the maximum size of inputCount
that is going to be presented to the AES encryptor.

For each call:

1) Xor the bytes of inputBuffer with the buffer
2) call Transform block
3) Xor the bytes of outputBuffer with the buffer

The wrapper is even symmetric! I can use the same one for Encrypt and
Decrypt.

I am going to be changing the padding mode however as I am padding packets
out to fill the Ethernet MTA. So I can simply specify that a round number
of AES blocks are used. So I can dispose of the ciphertext stealing part
(except for purposes of validating against the test vectors) as my code is
simply a special case of the general padding scheme.


The RFC would be sooooo much easier to read in the new HTML format.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210301/4b673bae/attachment.htm>