Fra https://www.ctf.ca/ctfweb/Documents/PDF/2009ctj/09ctj4-ainsworth.pdf -

I tillegg til å sikre integriteten til informasjonen presentert på kvitteringen, løsningen designet av Revenu Québec sørger for at strekkoden skannet av [håndholdt] leser produseres av sertifikatet levert av [Revenu Québec] til den spesifikke MEV [SRM] som genererer dette signatur. Signaturen er produsert av en kombinasjon av SHA-256 og ECC-224.

Denne metoden bruker et sertifikat som inkluderer en offentlig og en privat nøkkel utstedt for hver MEV [SRM] med informasjon som identifiserer MEV [ SRM] og restauranten.

Vi velger algoritmen for elliptisk kurve (ECC) for å redusere lengden på resultatet ( skal konverteres til en strekkode ) og for å opprettholde en god styrke.

Så tilsynelatende utgjør de forrige bitene i strekkoden en digital signatur, som vil forklare den høye entropien.

Jeg hadde en gang et sett med kvitteringer og tygget meg gjennom statistikken over hvor ofte symbolene gjentas. Det viser at det mest sannsynlig er 256 symboler, noe som vil gjøre at symbolraden inneholder 96 = 12 * 8 bits.

https://www.ietf.org/mail-archive/web /81attendees/current/msg00986.html

Når du sjekker Unicode-diagrammer, er nesten alle symbolene på siden U + 22xx, "Matematiske symboler". Jeg har ikke sporet opp resten, hvorav noen er alvorlig uklare, men noen ser ut til å være sans-serif hebraiske bokstaver. Jeg tipper at symbolene som ikke er i U + 22xx, skal erstatte noen symboler på den siden som er for mye som andre.

Det ser ikke ut til å være noe vanlig databehandlingsformål som symbolene kan tjene , siden all informasjon du ville være maskinbehandlet, ville du legge inn strekkoden. Min gjetning er at symbolene er en hash, et sammendrag eller en delmengde av informasjonen i strekkoden og fungerer som et "kvitteringsnummer" som mottakeren kan lese, slik at hvis to kjøpere kjøper det samme , etableringen kan ikke gi dem to kopier av en (registrert) kvittering, men må heller registrere to kvitteringer for å gi til hver av dem.

Denne forklaringen redegjør for hvorfor symbolene er lett gjenkjennelige. Det er også basert på en opplevelse i Musée de la civilization à Québec: Jeg kjøpte en te fra kafeen, og følgesvennen min kjøpte også en te, umiddelbart etter meg, fra samme kassereren. Kvitteringene våre hadde samme linje med symboler, en overraskende usannsynlig hendelse, noe som antyder at vi mottok duplikatkopier av en registrert kvittering.

Basert på noen få eksempler, her er en oversikt over noen felt som kan leses tydelig.

Kilde: https://github.com/fproulx/tastybits/blob/master /NOTES.md

Datasett: https://github.com/fproulx/tastybits/tree/master/sample-data

Uoffisiell spesifikasjon

• PDF417 strekkode med BASE64 kodet binær nyttelast
• Alltid 0x7A byte lang == 122 bytes == 976 bits
• Endianness vises å være Little Endian (Intel)
• [0x00, 0x39] Ukjent data. Skiller seg alltid fra regning til regning.
• [0x40, 0x43] MEV-serienummer
  • Merknader: venstrejustert binære 32-bits liten endian, null polstret ( 0x00)
• [0x44, 0x47] MEV-transaksjonsteller (monotont økende)
  • Merknader: venstrejustert binær 32- bits lite endian, null polstret (0x00)
• [0x48, 0x4B] Ukjente data
• [0x4C, 0x55] Unikt regnings- / transaksjonsnummer
  • Merknader: høyrejustert ASCII-tekst, mellomrom polstret (0x20)
• [0x56, 0x59] Faktureringstid
  • Merk: Antall sekunder fra MRQ Epoch (2009-01-01)
• [0x5A, 0x63] Ansattes navn
  • Merknader: ASCII-tekst mot høyre, hvitt mellomrom polstret (0x20)
• [0x64, 0x6B] Leverandørfelt, typisk tabellnummer, takeaway osv.
  • Merknader: ASCII-tekst med høyre linje, hvitt mellomrom polstret (0x20)
• [0x6C, 0x6E] TPS verdi i øre
  • Merknader: venstrejusterte binære 24-bits, liten endian, null polstret (0x00)
• [0x6F, 0x71] TVQ-verdi i øre
  • Merknader: venstrejusterte binære 24-bits, liten endian, nullpolstret (0x00)
• [0x72, 0x77] Totalpris (inkludert TPS + TVQ) i øre
  • Merknader: venstrejustert binær 24-bits, liten endian, null polstret (0x00)
• [0x78, 0x7A] Konstant data (0C: 43: 0E)