HMAC-sigill som aldrig godkänns (PHP)

Jag tror att jag behöver andra ögon på det här problem.

Så här är läget:
Vi har ett fixat ett eget system för autogirohantering som bättre passar oss än de generella affärssystemen. Den biten funkar utmärkt när vi kört ett längre test med manuell uppladdning till banken via internetbanken.
Så nästa steg i projektet var att automatisera överföringen fram och tillbaka med SFTP och allt där funkar också utom en detalj, HMAC-sigillet.

Jag håller på att bli tokig av leta information över vad jag kan ha gjort för fel och i just denna fråga är inte Bankgirot så behjälpligt heller. Så jag får testa mig fram och invänta svar på varje enskild testfil som kan ta evigheter och oftast innehåller följande:

"Anledning till att filen har makulerats: Filen är sigillerat med rätt nyckel men något i filen stör beräkningen av sigillet."

Filens sigill skapas såhär:

addSpace = funktion för att fylla ut rader med mellanslang
$kvv = verifiering att rätt nyckel används med godkänt resultat från Bankgirot
$sig = sigillet för innehållet som då inte är godkänt
$string = datum, verifiering och sigill ihopslaget

Referenserna jag använt mig av för detta:
https://www.bankgirot.se/globalassets/dokument/tekniska-manua...
https://www.bankgirot.se/globalassets/dokument/tekniska-manua...

Jag har testat med onlinebaserade HMAC-generatorer och får exakt samma resultat som det som skapas från PHP:s hash_hmac() (eller hash_hmac_file() ) med testnyckeln.
Jag har testat att använda radslut från Linux och Windows samt med och utan CRLF.
Jag har frågat Bankgirot om exempelfiler som har ett korrekt uträknat sigill men det är den enda typen av exempelfiler de inte har.

Det ska vara en massa tomrum och sådant i filen då alla rader ska vara 80 tecken långa och just denna bit har jag dubbelkollat att det inte är för mycket eller för lite mellanslag någonstans (vilket jag ser försvinner här, men det spelar mindre roll).

Vi kör med en LAMP-server och Swedbanks SFTP-som detta skickas till misstänker jag kör Windows då den saknar Rsync för överföringen men att SCP funkar.
Testöverföringarna har nu gjorts med Filezilla.
Filer som förs över försvinner efter relativt kort stund men jag har inte kunnat se något uppenbart som Filezilla skulle kunna ha gjort under överföringen. När det går på automatik så förs det över via SCP.

Nu är väl detta långt nog men jag försöker få med så mycket information som möjligt. Finns det något uppenbart jag missat eller har någon kanske till och med pyssla med HMAC-sigill för överföring till banken?

Tacksam för svar!

Normaliseringen har jag löst genom att ta bort alla möjligheter att ha ÅÄÖ (eller andra specialtecken). Så funktionen
mb_check_encoding() rapporterar ASCII, vilket jag tolkar som att det ska vara rätt. Stoppar jag in ett Ä så rapporterar den funktionen UTF-8.

Jag kanske feltolkar informationen, men för mig ser det ut som att när en fil skapas via PHP så finns det ingen CRLF i den om inte PHP_EOL anges.
Skapar jag en fil och testar med cat -A på den så ser resultatet ut såhär:
https://tenton.se/graphic/Screenshot_20220323_142444.png
$ = Linux-radslut
Det borde vara ett $ på sista raden också om CRLF skulle ha funnits.

Tack i alla fall för förslag

Jag tackar och bockar!
Jag hade misstolkat den biten och tog bara bort den sista radbrytningen. Då resten av filens innehåll var godkänd av banken så hade jag fått det till att övriga radbrytningar kunde vara kvar men att det inte fick finnas en "tom" radbrytning (som det exempelvis alltid blir när man skapar en textfil i Linux).

Fixade det med:

$test = str_replace (array("\r\n", "\n", "\r"), '', $test);

Jag tackar och bockar!
Jag hade misstolkat den biten och tog bara bort den sista radbrytningen. Då resten av filens innehåll var godkänd av banken så hade jag fått det till att övriga radbrytningar kunde vara kvar men att det inte fick finnas en "tom" radbrytning (som det exempelvis alltid blir när man skapar en textfil i Linux).

Fixade det med:

$test = str_replace (array("\r\n", "\n", "\r"), '', $test);