Příspěvky

1111

Hardware / Re:USB miner - jiné využití

« kdy: 17. 02. 2021, 16:58:08 »

nedokazuji si predstavit ty asicy pouzit na cokoliv jineho - mozna nejaka mala vyuzitelnost by byla v pripade jack-the-ripper lamace hesel, kde jsou nejake hashe, ale zas v zcela jinem formatu.

FPGA miner by sel prestavet lepe - pokud tedy nemate verzi s vypalenym klicem, k provozu jen firmwaru od vyrobce karty (jo, takove podlosti se taky najdou)

1112

Odkladiště / Re:České daňové přiznání a kryptoměny

« kdy: 17. 02. 2021, 15:26:37 »

Danit kazdou transakci - a jeji zisk.. to ani nejde, leda danit rozdil dvou transakci (nakup/prodej).
Ale kdyz prodelate, tak vam ztraty zrejme nevrati na danich :-)

Danit rozdil v hodnote na zacatku/konci roku: stejny problem.

Nejvic dava smysl snad tento postup - danit rozdil mezi nakupem crypto a jejim prodejem do klasicke meny, v pomerne casti vzhledem k objemu likvidovanych coinu. Pocitejte to proste jako "kakao" ci "zlato". Crypto totiz neni mena, spis komodita.

Tj. zmeny mezi coinama nemaj vliv - zalezi ciste na tom, kolik jste do toho vlozil penez (ty nedanite), a kolik jste toho prodal, a pokud vam zbylo jeste dve tretiny coinu, tak samozrejme odecitate jen tretinu nakladu od sumy kterou jste ziskal prodejem - danite cistej zisk.

1113

Hardware / Re:3.5" HDD bez nutnosti 12V / napájení 12V HDD "mobilně"

« kdy: 07. 02. 2021, 22:25:26 »

https://www.mini-box.com/OpenUPS2
ti udela ze 3 clanku 12V
2400mAh*3.7V *3 = 26.64Wh, pro 8W disk to je 3.33 hodin.

1114

Vývoj / Re:TCP bezpečnost

« kdy: 05. 02. 2021, 17:14:56 »

Nápad použít IPsec je zajímavý (pokud jste tedy svým zašmodrchaným komentářem myslel tohle), nicméně implementovat IPsec není nic jednoduchého.

Tak ono postaci nejake minimum (jedna sifra, jeden rezim), a protistrana se patricne nastavi.
Je to lepe testovatelne a neni treba vymyslet transportni kodovani.


Ohledne zbytku - bohuzel mam prakticke zkusenosti a onu hru na kocku a mys, kdy se bezpecnost zvysovala vsemoznym teoretickym zpusobem (padlo zde ve vlakne mnoho tipu a nic z toho opravdu nebyla prekazka), zastavilo az nasazeni specialniho biosu a sifrovanych medii, ktere pri jakemkoliv naznaku naruseni tripnou a vymazou klice. Proto kazdy, kdo to mysli s bezpecnosti vazne, nespoleha jen na sifry a metody, ale resi se to systemem bezpecnych enklav (to je ta moje pozadovana fyzicka bezpecnost) - HSM a pod.

Nejde o to, ze prolomeni muzete provest jednorazove na miste cinu - ale o to, ze po obfuskaci ("sifrovani") spojeni, bude dalsi nejslabsi clanek onen fyzicky endpoint. A kdo bude mit zajem.. si pro nej fakt prijde. Pak vam prijde treba reklamace, ze "sory, ono se z toho zakourilo", tak to vymenite. Ale po teto udalosti, treba uz ta bezpecna sit neni jenom vase.. protoze je v ni nekdo dalsi.

Myslim ze resit protokol samo o sobe je malo - jestli to chce mit autor bezpecnejsi, mel by o tom premyslet jako o celku.

1115

Vývoj / Re:TCP bezpečnost

« kdy: 05. 02. 2021, 15:10:02 »

A tohle je to obri zdani bezpecnosti. Vy falesne duverujete necemu, co vam klient rekne - klidne muzete mit nejaky malware (ci antivirak), ktery se vam vlozi do sitove komunikace, prebali to SSL na jinak podepsany, podvrhne CA.

Tak ještě jednou a pomaleji. Když mám v ruce krabičku, ze které vedou dráty pro ovládání otevírání a zavírání dveří, nebudu složitě hackovat software v té krabičce, ale prostě se připojím přímo na ty dráty a tu krabičku úplně obejdu.

Pořád řešíte problémy, které nikdo řešit nechce.

Pokud je si autor 100% jisty ze mu klice a kod neunikne, plus server i ta spousta zarizeni odola fyzickemu utoku (coz je v realnem nasazeni opravdu nemozne splnit), tak bude cesta nejmensiho odporu nasadit symetrickou sifru nad daty ve formatu  "pocitadlo+payload+checksum". Jestli to presune z aplikacni urovne nekam hloub do IP, tak z toho mame co? Zcela klasicky IPsec.

Takze nevymyslejte lamersky TLS ohejbak, kdyz to jde udelat zcela standardne, dokonce i s omezenymi zdroji ktere ta aplikace pry ma.

1116

Vývoj / Re:TCP bezpečnost

« kdy: 05. 02. 2021, 09:10:10 »

Utocnikovi se v pripade asymetricke krypto se postaci zmocnit jedne strany spojeni/systemu, a druha ho bude poslouchat na slovo.
A je zcela jedno, kdo drzi verejny a kdo privatni klic - mate jeden, mate nad-vladu nad protistranou.

Myslel jsem si, že vůbec nechápete princip asymetrické kryptografie. Děkuji, že jste nám to potvrdil.

Pro info – veřejný klíč se nazývá veřejný proto, že je veřejný, tj. může ho znát každý. Rozklikněte si v prohlížeči tady na Rootu v adresním řádku zámeček, tam budete mít možnost zobrazení certifikátu. A v certifikátu najdete veřejný klíč toho certifikátu vydaného pro root.cz. Víte, co s tím veřejným klíčem můžete udělat? Vůbec nic. Teda můžete ověřit, že komunikujete s protistranou, která k tomu klíči má privátní klíč.

A tohle je to obri zdani bezpecnosti. Vy falesne duverujete necemu, co vam klient rekne - klidne muzete mit nejaky malware (ci antivirak), ktery se vam vlozi do sitove komunikace, prebali to SSL na jinak podepsany, podvrhne CA.

Pokud uz chcete aplikovat chain of trust, tak to overeni NESMITE delat na tom samem zarizeni, protoze nemate jistotu zda neni kompromitovana sit nebo rovnou stroj. A jaksi z principu bude blby aby u kazdeho klienta stal clovicek s papirovym otiskem klicu (ktery jde samozrejme take podvrhnout). Proto rikam, ze ultimatni bezpecnost neexistuje.

1117

Vývoj / Re:TCP bezpečnost

« kdy: 04. 02. 2021, 22:49:21 »

Vypocetni kryptografie bez fyzicke bezpecnosti (klicu, vypoctu) nema vyznam.

Jaktože ne? Já to pochopil tak, že autor řídí pomocí PLC nějaký průmyslový proces, a nechce, aby ho někdo po cestě mohl řídit místo něj. A k tomu přesně se kryptografie používá. Když někdo vleze dovnitř k tomu PLC, tak je hezké, že může extrahovat klíče, ale také může ty dráty co z toho PLC vedou připojit kam chce a proces tak řídit rovnou.

Jestli budu chtit ridit nejaky takovy proces jako utocnik, tak rozhodne nebudu posilat nahodne pakety do Internetu. Ale pujdu na to aplikovane a zmocnim se jedne nebo druhe strany - na uspesny utok ani nemusite mit moc nad online koncem - casto postaci offline kopie/snapshot onoho zarizeni na jednom konci.

Pro me je fascinujici jak se dokaze teoreticky radit co je dokonaly - ale opomiji se zakladni vec - ten, kdo vam dokaze skodit, bude znat vas system lepe nez vy sami. A pak je tam jen faktor toho, co tou cinnosti ziska - at uz se jedna primo o penize, protoze se jedna o financni system, nebo vam jenom nenapadne rozhodi centrifugy v jadernem zarizeni...

1118

Vývoj / Re:TCP bezpečnost

« kdy: 04. 02. 2021, 22:29:45 »

Šel bych na to úplně jinak. Na server, který jak říkáš má veřejnou IP nainstalovat OpenVPN nebo  WireGuard. Pokud je to Linux, tak jsi šťastný člověk :_)
Na klientovi pak jen oVPN klienta a hotovo a nepotřebuješ to dávat ani na routery.

Tohle je velice marne reseni. Kdokoliv kdo ma pristup k HW pak ziska pristup - samozrejme ze to odstini 99% nahodnych utoku, ale to 1%, ktere zajima nejaky pozitivni prinost z cracknuti autorovy site si holt nejakou jeho krabicku k analyze/zneuziti sezene

A v čem je teda přesně problém když tohle někdo udělá? Samozřejmě nepředpokládám (i když podle úrovně dotazů…) že by měl autor globální klíče.

Vypocetni kryptografie bez fyzicke bezpecnosti (klicu, vypoctu) nema vyznam.
Mam pocit, ze autor se snazi zajistit nejakou zdanlive lepsi ochranu sveho reseni, nez je prakticky realizovatelna.

1119

Vývoj / Re:TCP bezpečnost

« kdy: 04. 02. 2021, 22:26:23 »

I kdyby jste pouzili sebelepsi asymetricke krypto pro podepisovani dat, tak prvni co utocnika napadne je vydolovat klic z fyzickeho zarizeni.

To je právě výhoda asymetrické kryptografie. Že privátní klíč pro podepisování bude jenom na serveru. U něj předpokládám, že je bezpečný.

Jak si predstavujete podepisovani dat odesilanych ze zarizeni na server, klicem, ktery je "bezpecne" na serveru?

Utocnikovi se v pripade asymetricke krypto se postaci zmocnit jedne strany spojeni/systemu, a druha ho bude poslouchat na slovo.
A je zcela jedno, kdo drzi verejny a kdo privatni klic - mate jeden, mate nad-vladu nad protistranou.

V pripade symetricke krypto se to zjednodusuje o to, ze klic je stejne a muzete ho ziskat od kterekoliv strany.

1120

Vývoj / Re:TCP bezpečnost

« kdy: 04. 02. 2021, 21:57:30 »

Šel bych na to úplně jinak. Na server, který jak říkáš má veřejnou IP nainstalovat OpenVPN nebo  WireGuard. Pokud je to Linux, tak jsi šťastný člověk :_)
Na klientovi pak jen oVPN klienta a hotovo a nepotřebuješ to dávat ani na routery.

Tohle je velice marne reseni. Kdokoliv kdo ma pristup k HW pak ziska pristup - samozrejme ze to odstini 99% nahodnych utoku, ale to 1%, ktere zajima nejaky pozitivni prinost z cracknuti autorovy site si holt nejakou jeho krabicku k analyze/zneuziti sezene :)

1121

Vývoj / Re:TCP bezpečnost

« kdy: 04. 02. 2021, 21:46:19 »

Bezpecny protokol ani zarizeni neexistuje - sebevic se budete snazit, vzdy existuje vice ci mene slozita cesta, jak jakoukoliv ochranu ktera je obalkou zakladni funkcionality obejit (viz CD, copy protection, hry, sw a pod). I kdyby jste pouzili sebelepsi asymetricke krypto pro podepisovani dat, tak prvni co utocnika napadne je vydolovat klic z fyzickeho zarizeni.

Zminilo se tady, co je to vubec za aplikaci, co potrebuje vyresit nejakou ochranu? Protoze urcity bezpecnostni kompromis lze najit na te aplikacni urovni, a realna aplikace by spis mela umet identifikovat narusitele a ochranu pak zalozit na ponekud vyssi urovni (je to srovnatelny se spamem - neco nezachytite, neco zbytecne zahodite.. dokonalost neexistuje).

1122

Hardware / Re:Slušný kompaktní foťák do 10 tisíc

« kdy: 04. 02. 2021, 00:43:52 »

RX100 bych zrovna prvni generaci nebral - ta ma FSI snimac, pak Gen2 a 3 maj BSI, Gen 4+ pak maj jeste lepsi (stacked), ty rozdily tam jsou - jednou se meni snimac, jednou sirka ohniska, jednou audio io vybava, jednou LCD flip.. a tak.. ono to se postupne obmenuje, ale ne vice veci naraz, spis jen jedna.

RX100 V4 pak umi natacet 4K, protoze CPU, ale my pouzivali ty snimaci z drivejsich modelu, a maj taky 4K60 rezim ale proste Sony nechtelo mit zbytecne dobrej fotak, takze to ty prvni tri generace "neumeli".

1123

Vývoj / Re:Má tu někdo zkušenosti s využitím PCI Endpoint Frameworkem v kernelu?

« kdy: 03. 02. 2021, 19:14:17 »

A z pohledu dat, je to "jenom změna pár hlaviček" a DMA jepřešoupne místo do USB fifo do PCIe fifo
Ten výslednej performance hit mě taky docela zajímá

XHCI imho nepracuje s high level streamy, ale ring bufferem pro transfer USB paketu - requestu a odpovedi.
Ale tak neni nic jednodussiho, nez se podivat do XHCI specifikace, podivat se co za primitiva to pouziva (zrejme dma+irq), jaky je format bufferu a pak to naroubovat na ten PCIe endpoint.

Performance hit tam vidim v tom, ze musite pres SW uzavrit smycku mezi requestem a odpovedi, takze tam bude velka latence / roundtrip, a pak to segmentovani payloadu do paketu, kterym musite pridat hlavicky, takze ono to nakonec nebude ciste DMA, ale sw preskladani.

Pokud ridite oba konce spojeni (jako FW pro iMX8, tak host drivery), tak by bylo lepsi ten cas obetovat do napsani optimalniho V4L2 driveru (na coz mozna snadneji najdete exampl, pro ten pcie endpoint), nez do vytvoreni XHCI abstrakce. A jako nestandardni reseni na pul cesty, by byla implementace vlastniho virtualniho USB kontroleru, kdy nemusite resit XHCI formatovani registru/bufferu, ale nejak to protistrane predate po svem.

Kdybych se mel ridit cenout a nechtel psat drivery, tak ten iMX8 vyhodim a pouziji UVC streamer ASSP od FTDI (FT600/601)

1124

Vývoj / Re:Má tu někdo zkušenosti s využitím PCI Endpoint Frameworkem v kernelu?

« kdy: 03. 02. 2021, 13:18:25 »

A to ma byt ciste virtualni implementace, nebo to bezi na skutecnem hw (jakem), ktery ma PCIe endpoint?

EDIT: to i.XM8 jsi asi chtel rict iMX8 - a pak se tedy divim, ze to chcete bastlit skrze PCIe, kdyz ten SOC ma rovnou dva USB3 porty ktere muzou fungovat jako device, takze by sis usetril jednu vrstvu, ktera bude v zamyslenem nasazeni velky performance hit.

PCIe endpoint device neznamena ze si tam muzes udelat jakykoliv realny zarizeni (na to jste meli pouzit FPGA), ale ze to podporuje typicky nejake DMA a tim to konci (napr. TI DSP toho hodne vyuzivaj).

1125

Odkladiště / Re:Zkušenost s Google-free telefony Huawei

« kdy: 03. 02. 2021, 11:21:13 »

Pritom by stacilo prosadit zakon, ktery rika ze tato elektronika z dovozu musi umoznovat odemknout bootloader.
Tj. ten odemykaci kod by mel byt bud soucasti baleni, nebo vygenerovatelny offline toolem na uzemi CR, napr. z IMEI, a zprostredkovani zajisti napr. operator na svych pobockach.

To je teda pěkná pitomost! S takovou by pak mohl někdo další třeba chtít, aby u procesorů bylo zákonem nařízeno, že musí mít odemčený násobič apod., ne? Kam na ty nápady proboha chodíš...

Tak holt vyrobce bude muset lepe testovat a binovat, pripadne nekategorizovat podle modelu, ale prodavat procesory na megahertzjadra jako maso... treba 1MHzCore = 0.2kc, takze kdyz kousek pojede v delsim testu stabilne u 4C/4GHz, bude stat 3200.-

Bohuzel omezovani na ktere vliv spis pribiva - viz nejnovejsi automotive vymysl, s omezovaci rychlosti.