Áno, škoda že nie je k dispozícii nejaký dokument podpísaný verejným kľúčom niekoho s vládnej koalície. Asi by sa oplatilo vytvoriť zbierku na jeho prelomenie a všetok jeho majetok previesť napríklad na nejakú charitu. Podľa súčasných zákonov by išlo o nenapadnuteľný prevod. Potom by sa snáď zobudili.
Ako je všeobecne známe, už pred 1.7.2017, odkedy sú slovenské právne subjekty povinné používať elektronickú komunikáciu, naši vládni predstavitelia vedeli že je to celé nahovno. Vôbec ich nenapadlo platnosť zákona minimálne dočasne pozastaviť, kým sa všetko vysvetlí. Oni sa správajú ako pri nevere: všetko zatĺkať, zatĺkať a keď sa na niečo príde, tak zatĺkať ďalej.
Linux používá vlastní metodu pro generování náhodných čísel, kde tyto čipy představují pouze jeden ze vstupů, takže i kdyby tyto čipy generovaly jen dvě možnosti - samé nuly nebo jedničky - tak pořád budou zvyšovat bezpečnost. Linus o tom před pár lety hovořil. Jelikož OpenWrt je založené na Linuxu, tak se jich to bude týkat jen tehdy, pokud by autoři sahali na implementaci generátoru náhodných čísel tak, že by se spoléhal čistě na kryptografický čip - což pochybuji že by někdo soudný dnes udělal (zbytečné náklady vynaložené na implementaci "single point of failure").
Těch víc zdrojů entropie je pro generování náhodných čísel, ale ta chyba se týká RSA klíčů. Pro některé situace se používají hardwarově generované klíče, kdy TPM privátní klíč vygeneruje a šifruje s ním, používá se to třeba pro full-disk encryption či digitální podpisy. Smyslem je, že ten klíč nejde nijak přečíst, ani cold boot attackem ani bootkitem se tak ke klíči nelze dostat. Právě tyhle klíče jsou v těch vadných čipech faktorizovatelné.
Dle schematu (Omnie https://www.turris.cz/doc/_media/rtrom01-schema.pdf) je pouzit cip ATSHA204A-MAHDA-T od Atmelu (http://www.atmel.com/images/atmel-8885-cryptoauth-atsha204a-datasheet.pdf).
Odhaduje se, že problémem trpí přibližně třetina podobných řešení dostupných na trhu.
Tohle je odkud?
BTW ten offline tester má akorát pár prvočísel hardcodovaných a proto dává false negative výsledky.
Podobný osud postihnul taiwanské eID karty - https://smartfacts.cr.yp.to/smartfacts-20130916.pdf
Online nástroj (ten první) mi testované klíče z eID občanky označil jako prolomitelné. Když jsem mu dával na test i nějaké vygenerované od OpenSSL, tak vypadalo, že je správně rozliší.
Takže online a offline detektor jsou určitě rozdílné.
Ten druhý online nástroj, co zkouší batch GCD, mi je naopak označil na bezpečné. Evidentně mají rozdílné databáze.
Nevím ale jak funguje ten první online detektor, není nikde zdroják.
Nemám tušení, snad ne, ale jistota je jistota. Navíc udělat takovou nějakou čtečku která by vám umožnila identifikovat každého kdo kolem vás projde - to je výzva pro opravdové HACKERY (hodné toho slova) jak vyšitá.
Rozhodně bych to ale takhle udělal s platební kartou. Když se kouknete, kdo má bezkontaktní platební kartu (už docela dost lidí) a riskuje tím že si jí do toho alobalu nedá (drtivá většina) - tak to je přesně obrázek dnešní ovčanské společnosti - hlavně že je nikdo nemůže nařknout z toho, že jsou paranoidní...
Nie nie je, OP musi byt strceny do citacky.
Bezkontaktne (RFID) su napriklad pasy, existuje dokonca mobilna aplikacia ktora udaje z pasu vratane fotky vie precitat (ak ma mobil NFC). Je to ale ciastocne chranene - na povolenie pristupu treba zadat cislo pasu a datum narodenia drzitela inak tie udaje cip z pasu neposkytne.
U mě to normálně funguje (https://keychest.net/roca). Opět správně rozliší klíč generován od Yubikey 4 a klíč generován na počítači.
Export s:
gpg -a --export KEYID
A pak to dát tomu nástroji.