polyval, ghash: Add flavors for Little Endian and Big Endian

[makavity]

According to this issue, bundled ghash should be removed from belt-dwp crate.

Could you clarify your preferred approach for this?
I suggest, we should add generic param for arithmetic, like in CTR crate.

@newpavlov

[newpavlov]

I think we can start we the naive approach of introducing a generic parameter for byte order to see whether it would be sufficient for belt-dwp and mgm. But I also wonder if we could also use it to abstract over differences between polyval and ghash.

[tarcieri]

FWIW I plan on refactoring those crates soon, and introducing FieldElement types which will hopefully make these more exotic use cases easier

[tarcieri]

What exactly do you want here? POLYVAL is effectively the little endian equivalent of GHASH.

Is there some other bespoke little endian GHASH variant that's distinct from POLYVAL?

[newpavlov]

I guess we should check whether mgm and belt-dwp can be implemented using polyval.

[makavity]

@newpavlov have no luck with that. Looks like flavor for arithmetic endian is the only approach to do that.

[tarcieri]

If you'd like I can add a FieldElement type to ghash which is the same shape as the one in polyval and handles the reversing for you. It really is just an endianness issue: the inputs and outputs of POLYVAL multiplication need to be byte-reversed, otherwise they're the same operation.

[makavity]

According to #202

#[test]
fn test_a18() {
    let u = hex!("34904055 11BE3297 1343724C 5AB793E9");
    let v = hex!("22481783 8761A9D6 E3EC9689 110FB0F3");
    let expected = hex!("0001D107 FC67DE40 04DC2C80 3DFD95C3");

    let mut u_block = Block::from(u);
    u_block.reverse();
    let u_polyval = FieldElement::from(u_block).mulx();

    let mut v_block = Block::from(v);
    v_block.reverse();
    let v_polyval = FieldElement::from(v_block).mulx();

    let result_polyval = u_polyval * v_polyval;

    let mut result_ghash: Block = result_polyval.into();
    result_ghash.reverse();
}

What is the better way to implement it?
Expose FieldElement from GHash, like a hazmat feature in polyval?

[tarcieri]

Is that working for you?

I think yes, ideally ghash could expose a type just like polyval::hazmat::FieldElement that works with GHASH's polynomial

[makavity]

Oh, i forgot about assert. Sorry. No, it doesn't work.
Looking for the correct way..

[makavity]

Looks dirty, but works. I think, expose FieldElement is fine.

use hex_literal::hex;
use polyval::Block;
use polyval::hazmat::FieldElement;

#[test]
fn test_a18() {
    let u = hex!("34904055 11BE3297 1343724C 5AB793E9");
    let v = hex!("22481783 8761A9D6 E3EC9689 110FB0F3");
    let expected = hex!("0001D107 FC67DE40 04DC2C80 3DFD95C3");

    let mut u_mapped = Block::from(u);
    u_mapped.reverse();
    for byte in u_mapped.iter_mut() {
        *byte = byte.reverse_bits();
    }
    let u_polyval = FieldElement::from(u_mapped);

    let mut v_mapped = Block::from(v);
    v_mapped.reverse();
    for byte in v_mapped.iter_mut() {
        *byte = byte.reverse_bits();
    }
    let v_polyval = FieldElement::from(v_mapped).mulx();

    let mut result: Block = (u_polyval * v_polyval).into();
    for byte in result.iter_mut() {
        *byte = byte.reverse_bits();
    }
    result.reverse();

    assert_eq!(result, Block::from(expected));
}

[tarcieri]

Yeah, needs a higher level of abstraction, but I'm glad you got it working

[makavity]

Hey, @tarcieri !
Wanna fix this, because belt-che is already implemented and just copies that logic.
Could you please clarify your approach?
Should we expose FieldElement from GHash with hazmat feature (in terms of ghash polynomial), or should I bundle FieldElement abstractions for LE convention into belt crates?