ID Poruke

Oct 23, 2012 at 11:25 PM

Čitam sve o fiskalizaciji evo već 4 sata i sve sam našao, manje više sve mi je teoretski jasno ali nigdje ni slova nisam našao o identifikatoru poruke. 

Piše da mora biti jedinsteven. Vidim da je neki hash ali kako i na koji način ?????

Gdje je to objašnjeno ?

 

Hvala.

Coordinator
Oct 24, 2012 at 7:09 AM

ID Poruke - UUID, GUID, uniqueidentifier -http://en.wikipedia.org/wiki/Universally_unique_identifier

Pogledaj i ovo: http://fiskalizacija.micro-process.hr/forum/index.php?topic=107.msg499#msg499

Oct 24, 2012 at 7:26 AM

Ovo prvo sam vidio. 

Ovo drugo ne ali trneutno ne mogu to vidjeti jer se i tamo moram regat.

 

Hvala. Proučit ću.

Coordinator
Oct 24, 2012 at 7:29 AM
Edited Oct 24, 2012 at 7:30 AM

Evo citat kolege (Tomislav Šereg, MAMM d.o.o.), sa spomenutog linka:

"

Različitih UUID-ova ima 2^128 (ako se naprosto gleda broj bitova), a iznosi se da bi teoretski bilo moguće izračunavati 10.000.000 UUID-ova u sekundi po svakom računalu na svijetu kroz 3.240 godina. Odatle se vidi da su ovako zamišljeni identifikatori pogodni za označavanje i vrlo kratkovječnih i vrlo dugovječnih objekata. To sam pročitao u nekom tehničkom opisu. Nisam siguran kako su došli do te brojke, ali imam neku ideju.

DCE-ov algoritam generiranja UUID-ova bi se trebao "preliti" negdje oko 3400. godine.

Format UUID-a je: Prvih 8 okteta su oznaka vremena i inačica varijante UUID-a, slijedeća 2 okteta nose informaciju o monotonosti sata i varijanti strukture UUID-a i zadnjih 6 okteta su identifikator čvora. 

Znači, postoje različite varijante strukture UUID-a, a svaka varijanta strukture može dolaziti u više inačica. Garantira se, međutim, da će sve inačice iste varijante imati istu strukturu.

U DCE-ovoj varijanti, u inačici 1, oznaka vremena u prvih (najlakših) 8 okteta je 60-bitovni UTC-broj 100-nanosekundnih perioda od ponoći, 15. kolovoza 1582. godine (od trenutka primjene gregorijanske reforme kršćanskog kalendara). Ostala 4 bita su, dakle, inačica DCE-ove varijante, tj. binarno "0001".

Srednja 2 okteta sadrže u prvim bitovima oznaku varijante, ali je broj bitova varijabilan. Prvi bit 0 indicira rezerviranu varijantu, prva dva bita 10 indiciraju da se radi o DCE-ovoj varijanti, prva tri bita 110 indiciraju da se radi o Microsoftovoj rezerviranoj varijanti, prva četiri bita 1111 su rezevirana kombinacija za buduće definicije (ne znam postoje li u međuvremenu). U DCE-ovoj varijanti "10" ostalih 14 bitova sadrže vrijednost registra za praćenje monotonosti sata (za detekciju slučaja kada je trenutno vrijeme sata manje od vremena kada je bio generiran posljednji UUID) - tako se spriječava generiranje duplikata.

Posljednjih 6 okteta su jedinstveni identifikator "čvora". U DCE-ovoj varijanti se pretpostavlja da generator UUID-ova uvijek ima na raspolaganju neku 48-bitovnu IEEE 802 mrežnu adresu, koje bi - barem u principu - trebale biti jedinstvene za svaki NIC ikada proizveden. Čuo sam da se u praksi zna dešavati da dvije mrežne kartice imaju istu MAC adresu, pa toliko o tome. Microsoftova implementacija GUID-ova na ovo mjesto stavlja nekakvu slučajno generiranu vrijednost ukoliko računalo ne raspolaže mrežnom karticom, što danas valjda i nije često slučaj.

Definiran je posebni nil UUID kojem su svi bitovi nule.

Znači, ako se promatra da je prvih 60-bitova UUID-ova zapravo brojač 100-nanosekundih intervala od 15. 8. 1582. onda na svakom čvoru/računalu ima UUID-ova za 100 * 2^60  nanosekundi generiranja, odn. za cca. 3655 godina, tj. do 5237. godine, odn. za još 3225 godina. Znači, gornja procjena o 3240 godina je rađena negdje 1998. godine. I stvarno, iz veljače te godine potiče i draft ove specifikacije. Naravno, računalo koje generira UUID-ove sporije od jednog svakih 100 nanosekundi neće moći generirati svih 2^60 brojeva, a ono koje bi generiralo i brže bi ih dupliciralo. Mislim da se u LHC-u čestice stvorene pri koliziji protona pobrojavaju UUID-ovima.

Postoji upis na jednom blogu na MSDN-u koji malo pojašnjava logiku iza registra za praćenje monotonosti. To je naprosto brojač koji se uveća za jedan svaki puta kada računalo zaključi da je generiralo UUID koji je već jednom generiran.

Ovakva struktura UUID-ova je leksikografski usporediva. UUID-ovi se poredavaju uspoređivanjem okteta od najlakšeg do najtežeg. Čitljivi zapis UUID-a (5 grupa heks. znamenaka razdvojenih crticama) je također usporediv i daje isti poredak.

DCE-ov algoritam generiranja UUID-ova osigurava:
- UUID-ovi su jedinstveni unutar danog čvora, verzije i varijante, pa time jedinstvenost vrijednosti čvora generatora znači univerzalnu jedinstvenost generiranog identifikatora;
- svi UUID-ovi iste varijante imaju jednaku strukturu;
- jedinstvenost se održava i u slučaju povratka sata i iznenadnog rušenja sustava;
- generiranje UUID-ova brže od rezolucije sistemskog sata je moguće, ali u slučaju prevelikog opterećenja zahtjev može biti odbačen ili generiranje usporeno.

Praćenje monotonosti sata računala je važno za rad algoritma za generiranje UUID-ova. Vjerojatnost generiranja identičnih UUID-ova se povećava ukoliko se zamijeni vrijednost čvora, npr. izgradnjom mrežne kartice iz jednog i ugradnjom u drugo računalo - ovo drugo računalo može generirati UUID koji je generiralo prvo računalo. Tada se registar za praćenje monotonosti sada mora inicijalizirati na slučajnu vrijednost. Moguće da OS-ovi to čine automatski kada biblioteka jezgre otkrije da koristi novi broj čvora -- to ne znam.

Programeru koji generira GUID-ove/UUID-ove se preporuča održavati bazu podataka istih zbog:
- spriječavanja slučajne upotrebe istog GUIDa dva puta,
- jednostavnije i sigurnije usporedbe pomoću programa i
- dostupnosti jedinstvenog izvora informacija u slučaju bilo kakvih drugih problema.

Znači, može se zamisliti neko računalo (ili više njih) koje glumi generator UUID-ova i distribuira ih korisnicima na zahtjev. Ne znam koliko to ima smisla danas, osim možda ako netko nema iskustvo da stanoviti proizvođači mrežnih kartica često dupliciraju MAC adrese, pa se odluči generirati svoje UUID-ove na računalu koje ima mrežnu karticu "kvalitetnog" proizvođača. No, ne znam što bih o tome mislio.

Važno je primjetiti da ovakvi UUID-ovi nisu kriptografski sigurni, jer se iz njih lako sazna MAC adresa računala i vrijeme generiranja UUID-a, pa se onda lako može pogoditi i slijedeći generirani broj. Zato oni sigurno nisu dobri tamo gdje trebaju slučajno generirani identifikatori.


 


Gore je, dakle, opisana varijanta "01" (DCE-ova standardna) u inačici "0001". Postoje još i inačice "0010" (2), "0011" (3) i "0100" (4). 

U inačici 4 se za sva polja koriste slučajno ili pseudoslučajno generirane vrijednosti - znači svi bitovi osim varijante i inačice, osim tih 6 bitova. U takvom UUID-u postoji 122 bita koji su manje ili više slučajni.

Zbog toga što inačica 1 nije kriptografski sigurna, Microsoft je s Windowsima 2000 prešao s inačice 1 na inačicu 4 svojih UUID-ova (tj. GUID-ova, kako ih oni zovu). Dok se za inačicu 1 stvarno može reći da postoji (ili je moguće uz malo pažnje osigurati) garanciju jedinstvenosti, za inačicu 4 se treba pouzdati u vjerojatnost. Koja je stvarno, stvarno velika, ako algoritam generiranja pseudoslučajnih brojeva dobro distribuira iste. A pretpostavljam da ih distributira, tj. da se koristi nekakav kriptografski primjenjiv generator pseudoslučajnih brojeva.

Ne vidim zašto bi za identificiranje računa bio potreban kriptografski siguran UUID, kada je poanta računa da sadrži informaciju o mjestu i vremenu nastanka. A upravo to je ono što i UUID u inačici 1 i razotrkiva. :)

Na Windowsima se UUID u inačici 1 može generirati funkcijom UuidCreateSequential, dok se u inačici 4 generira funkcijom UuidCreate ili System.Guid.NewGuid kako je već napisano.

"