Einzelnen Beitrag anzeigen

Kas Ob.

Registriert seit: 3. Sep 2023
457 Beiträge
 
#14

AW: Umfrage/Architekturfrage zur DEC

  Alt 20. Mai 2025, 11:14
Here my progress so far..
It includes heavily edited base classes too (not sure if that stays that way) - it is a start and I'm not expecting
this to be anyway close to a final architecture/working example.

The poly1305 test case works, as well as the base chacha20 encoding.
The tag is still not working....

When this works I will add an AVX version of the chacha cipher and try to create simd versions of the poly1305 update...
Something is OFF, i didn't run the code, might be later, but this part is perplexing me
Delphi-Quellcode:
procedure TPoly1305.InitInternal(const InitVector: T32ByteArray);
begin
     FillChar(FH, sizeof(FH), 0);

     ///* r &= 0xffffffc0ffffffc0ffffffc0fffffff */
// st->r[0] = U8TOU32(&key[0]) & 0x0fffffff;
// st->r[1] = U8TOU32(&key[4]) & 0x0ffffffc;
// st->r[2] = U8TOU32(&key[8]) & 0x0ffffffc;
// st->r[3] = U8TOU32(&key[12]) & 0x0ffffffc;
     FR[0] := U8ToU32(@initVector[0]) and $0fffffff;
     FR[1] := U8ToU32(@initVector[4]) and $0ffffffc;
     FR[2] := U8ToU32(@initVector[8]) and $0ffffffc;
     FR[3] := U8ToU32(@initVector[12]) and $0ffffffc;


     FNonce[0] := U8ToU32(@initVector[16]);
     FNonce[1] := U8ToU32(@initVector[20]);
     FNonce[2] := U8ToU32(@initVector[24]);
     FNonce[3] := U8ToU32(@initVector[28]);

     fNum := 0;
end;
And it is really from here https://github.com/openssl/openssl/b...305/poly1305.c
I see the clipingof the lower 2 bits for 4,8 and 12, but don't see the cliping of the highest 4 bits for 3,7,11 and 15.
From https://en.wikipedia.org/wiki/Poly13...on_of_Poly1305
Zitat:
The secret key r = ....
In all cases, use the standardized version from https://www.rfc-editor.org/rfc/rfc7539#section-2.5 this one is the most important and has the pseudo code in full, which also dictate :
Zitat:
o r[3], r[7], r[11], and r[15] are required to have their top four
bits clear (be smaller than 16)

o r[4], r[8], and r[12] are required to have their bottom two bits
clear (be divisible by 4)
...

void poly1305aes_test_clamp(unsigned char r[16])
{
r[3] &= 15;
r[7] &= 15;
r[11] &= 15;
r[15] &= 15;
r[4] &= 252;
r[8] &= 252;
r[12] &= 252;
}
So unless the code form OpenSSL is doing some arithmetic tricks and over optimized it is missing parts or has different implementation somewhere.
Kas
  Mit Zitat antworten Zitat