Vlákno názorů k článku Pohled pod kapotu formátu WebAssembly: nízkoúrovňová náhrada JavaScriptu od Marek - Ve WASM mi chybí kryptografické funkce/instrukce. Hlavně AES...

Ve WASM mi chybí kryptografické funkce/instrukce. Hlavně AES případně SHA-1/SHA-256. Nebo GCM. Téměř každá architektura dnešních CPU na které WASM cílí má nějakou formu HW akcelerace pro kryptografii. Dělat crypto ve webovém browseru v JS je obecně peklo, například window.crypto­.subtle se chvástá tím jak je low level a přitom ani neumí streaming digest. To udělali naschvál tak špatně, nebo to jsou "jenom" diletanti?

to je pravda. Ono je to ale těžký, například než byly vyspecifikovány vektorové instrukce (ty WASM umí, 128bitové floaty), tak přišly SIMD s 256bitovými a 512bitovými registry a WASM je zase vzadu. A dalo by se pokračovat - bf16, float16 pro AI atd. ...

Problém je, že to musí fungovať na všetkých architektúrach, nie len na x86_64. Nerobia to ani naschvál, ani nie sú diletanti. Podľa mňa to časom bude, tak isto ako v Jave nebolo všetko hneď.

Možná teď mícháme dvě věci dohromady. Všechny architektury: Jasně, chápu. ALE jak AES, tak SHA-1 (a SHA-256) jsou standardy psané anglicky. Jsou často a všude používané, dokonce tak, že některé (ne všechny) CPU architektury mají pro ně speciální HW instrukce / akcelerátory. Na WASM se můžeme dívat jako na další CPU architekturu a mohlo by to tam být. Nemuselo, ale mohlo. Na podkladové CPU architektuře, kde to není, by to stále fungovalo korektně. A rychleji, než to prgat po jednotlivých WASM instrukcích. Podobně jako garbage collection. Můžeš si ho napsat sám j jazyce, který kompiluješ do WASM, nebo to nechat na browseru (WASM VM) samotném, protože ten to stejnak už umí kvůli JS. GC ve WASM zatím nemáme, ale brzy budeme mít. (Na WASM se můžeme dívat jako na run time prostředí.) Stejně tak AES i SHA browser dnes také již umí kvůli HTTPS.

Za druhé streaming digest. Naprosté diletantství na straně tvůrců JS (nikoli WASM). Je to novinka v browserech pro tvůrce JS aplikací. Na stránkách Mozilla developers jsou všude veliké červené vykřičníky jak je to low level a advanced a tak. ALE abys spočítal digest z nějakých dat, tak ta data musíš mít VŠECHNA najednou současně v RAM. To snad ne. Neumožňují ti si držet nějaký stav a postupně do něj sypat data tak, jak ti pomalu postupně přicházejí po síti. Vždyť je to nějakých ±128 bajtů stavu. Zase, je to popsané v příslušném standardu NIST FIPS 180-4 a NIST FIPS 202.

WASM nie je ASM ale bytecode. Davat don vsteky specialne alternativy instukcii pre procesory nie je dobry napad.

Napriklad .NET to riesi cez inhristics, a teda namiesto spcielnej instrukcie volam specialnu funkciu, ktoru prelozi JIT bud na SIMD/AES instrukciu procesora, ked ju procesor ma, alebo pouzije fallback.

Ale suhlasim s tym, ze crypto JS APi navrhli diletatnti a pouzivat akukolvek kryptografiu v browseri nie je moc dobry napad (povedzme este ten hash hej, ale sifrovat to je uz dvojsecna zbran).

Myslím, že aj ten sandboxing vo web assebly zohráva úlohu, to obmedzuje použitie rôznych intelových vychytávok + intel je kitchensing architektúra. Je to potrebné spraviť tak, aby to bolo bezpečné (nevravím o vašej kryptografiu), multiplatformné a ešte to musí bežať aj na serveri aj v prehliadači rovnako. Ja si nemyslím, že sú diletanti, alebo že chcú škodiť, len ten projekt musí splniť niekoľko obmedzení, tak im to proste trvá.

Komu sa to nepáči, ten môže ísť na lampáreň, asi tak :(

A v tom pripade by nebolo lepsie pouzit tu Javu hned?

Tipujem, že predrečník je obmedzený na javascript/we­bassembly v browseri. Ináč by samozrejme asi použil niečo iné.

Nejsou to diletantni? No, já teda v JS píšu už hodně let ale čím déle, tím víc si tím nejsem jist. Nemá cenu si něco nalhávat: mnoho standardních API je příšerných a nemá to jen historické důvody.

Vytvorenie štandardného API je umenie možného, nie je cieľom uspokojiť expertov z diskusie root.cz.

Ty experty to pak jenom živí, že... Všiml jste si, že to API má sloužit primárně jim?