Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - MarekKnapek

Stran: [1] 2
1
Sítě / Re:Funguje vám Česká Televize?
« kdy: 22. 08. 2025, 12:04:11 »
šifry v nejvyšší kvalitě: 256 bit ECDH (P-256)

Mám pocit, že 25519 je vyšší kvalita než P-256. Nebo tomu tak není?

2
Server / Re:Rychlejší poskytovatel hostingu než Vedos
« kdy: 09. 06. 2025, 22:35:49 »
Jak těžký by pro tebe bylo nainstalovat si vlastní OS, web server, WordPress, databázi, apod? Hetzner nabízí 2 CPU, 4 GB RAM, 40 GB HDD, za 4.59 EUR / měsíc. Nebudeš mít žádný problém s výkonem. Můžeš si tam instalovat co chceš, jak chceš, nikdo tě nebude omezovat. Na druhou stranu si budeš muset dělat zálohování, bezpečnostní záplaty, konfiguraci všech těch programů/serverů sám.

4
Vývoj / Re:Zkrácení haše pro identifikaci
« kdy: 28. 02. 2024, 08:43:51 »
Pokud si ty hashe generujete sám, mohou se hodit algoritmy a kterých si můžete vybrat délku hashe. Pro spoustu use-case je to dobré řešení.

Doporučuji nějakou XOF funkci, třeba SHAKE (varianta SHA3).

6
Server / Re:Levné hostování velkého množství dat
« kdy: 14. 02. 2024, 04:20:13 »
Tady mají sice malý HDD ale unmetered traffic za 96$. Možná by to šlo spojit s úložištěm, které není dostupné všem z internetu, ale poze jednomu účtu (typu ulozto). https://www.fdcservers.net/configurator?fixedFilter=20&fixedFilterType=bandwidth_option

7
Server / Re:Levné hostování velkého množství dat
« kdy: 14. 02. 2024, 03:47:43 »
> Jinak take premyslim, zda do Hetzeru jit.

Mám tam malý server 16GB/8core/30€. Tuším že traffic je do 20TB zdarma. Linka zhruba 1.5Gbps. Za poslední rok 1 výpadek na zhruba 10 hodin. Žádné info ani omluva, když jsem se zeptal co se stalo, řekli mi, že na node kde běží můj server musela být provedena urgent maintenance.

8
Server / Re:Levné hostování velkého množství dat
« kdy: 01. 02. 2024, 01:10:17 »

9
Server / Re:Komprimovat či nekomprimovat data pro HTTP
« kdy: 14. 01. 2023, 21:05:37 »
samozrejme predkomprimovat subory je uplna blbost

To samozřejmě není. Došlo tu k nedorozumění, každý mluvíme o trochu něčem jiném. Já mluvím o statickém obsahu jako jsou například za prvé css a js součásti html, nebo za druhé csv, log, txt data ke stažení. Je lepší je 1x-3x zkomprimovat dopředu (pokaždé jinou metodou) a poté je x-krát poslat klientům na každý jejich požadavek (podle toho jakou umí kompresi). Přesně za tímto účelem Google v roce 2013 představil zopfli/brotli, program, který komprimuje do starého dobrého zlibu, který umí všechny současné i minulé prohlížeče, ALE produkuje mnohem menší soubory za cenu mnohem, mnohem, mnohem větší spotřeby CPU a RAM. To nám ale nevadí, protože komprimujeme pouze 1x a pak milionkrát posíláme již zkomprimovaný soubor a tím šetříme traffic a https šifrování.

Ty mluvíš o za prvé datech typu png, jpeg a mpeg. Ty už jsou uvnitř zkomprimované a je tedy nesmysl je dále komprimovat http kompresí. Co je ale možné, je mít na serveru x variant stejného obrázku/fotky nebo videa v různých formátech jako je např. jpeg, jpeg-xl, heic, webp nebo mpeg, h264, h265, vp9, av1 a nabídnout klientovi všechny varianty a on si vybere tu nejlepší, kterou umí.

Za druhé mluvíš o výstupech z API, tam je to na zvážení, protože jde o dynamická data. Záleží na trade-off mezi časem potřebným k vygenerování dat + jejich kompresi vs ušetřený bandwidth. Na velmi pomalé lince se vyplatí komprimovat. To už tu rozebrali jiní diskutující.

10
Server / Re:Komprimovat či nekomprimovat data pro HTTP
« kdy: 13. 01. 2023, 17:28:54 »
Tady to vypadá jako nedostatek CPU, protože komprese probíhá on-line (v okamžiku vyřizování requestu). Hádám správně? Pokud ano, doporučuji komprimovat offline. To znamená, že dopředu vyberu statické resources, které chci komprimovat (typicky JavaScripty, txt logy, CSV dokumenty, apod), tyto 1x zkomprimuji pomocí zlib/brotli/gzip. Následně při vyřizování requestu se podívám jakou kompresi klient umí a podle toho vyberu (už zkomprimovaný) soubor na disku a pošlu ho.

11
Vývoj / Re:HMAC, SHA1 (C++/AVX2 VS2022)
« kdy: 03. 01. 2023, 03:33:43 »
Ahoj Kevile, matematika ti moc nejde, co? Říkáš, že zvládneš spočítat 62^8 netriviálních operací za 40 ms? To máme 62^8/40 netriviálních operací za ms, neboli 62^8/40/1000 netriviálních operací za μs, neboli 62^8/40/1000/1000 netriviálních operací za ns. Furt je to zhruba 5.5 miliónu netriviálních operací každou nanosekundu. Při rychlosti 5GHz, to je stále milión operací za takt. To asi ne, co?

12
Vývoj / Re:HMAC, SHA1 (C++/AVX2 VS2022)
« kdy: 10. 12. 2022, 00:12:10 »
Tak jsem se na to podíval a určitě tam máš chybu ve výpočtu SHA-1, ve druhém a dalším bloku, kód [1] nahraď kódem [2].

[1]
Kód: [Vybrat]
void SHA1(__m256i* indata) {
    uint32_t pole[80];
    __m256i data;

    uint32_t h0 = 0x67452301, a = h0;
    uint32_t h1 = 0xEFCDAB89, b = h1;
    uint32_t h2 = 0x98BADCFE, c = h2;
    uint32_t h3 = 0x10325476, d = h3;
    uint32_t h4 = 0xC3D2E1F0, e = h4;

    for (int k = 0; k < 2; k++) {

        data = _mm256_load_si256(indata + k * 2);
        _mm256_store_si256((__m256i*)pole, data);
        data = _mm256_load_si256(indata + k * 2 + 1);
        _mm256_store_si256((__m256i*)pole + 1, data );

        uint32_t temp;

        for (int i = 0; i < 80; i++) {

[2]
Kód: [Vybrat]
void SHA1(__m256i* indata) {
    uint32_t pole[80];
    __m256i data;

    uint32_t h0 = 0x67452301;
    uint32_t h1 = 0xEFCDAB89;
    uint32_t h2 = 0x98BADCFE;
    uint32_t h3 = 0x10325476;
    uint32_t h4 = 0xC3D2E1F0;

    for (int k = 0; k < 2; k++) {

        data = _mm256_load_si256(indata + k * 2);
        _mm256_store_si256((__m256i*)pole, data);
        data = _mm256_load_si256(indata + k * 2 + 1);
        _mm256_store_si256((__m256i*)pole + 1, data );

        uint32_t temp;
        a = h0;
        b = h1;
        c = h2;
        d = h3;
        e = h4;
        for (int i = 0; i < 80; i++) {

13
Vývoj / Re:HMAC, SHA1 (C++/AVX2 VS2022)
« kdy: 08. 12. 2022, 22:12:35 »
Ahoj, nedávno jsem implementoval (mimo jiné) jak SHA-1 tak HMAC v čistém C (C89/C90). Mám to na GitHibu a běží to i ve Visual Studiu. Je to otestované a funguje to zaručeně správně (použil jsem fuzzing a jako oracle Windows crypto API). Takže do mé implementace můžeš hodit svůj input a prokrokovat si to v debuggeru. Nepoužívám ovšem ani AVX ani SSE ani AES-NI. Je to k dispozici na https://github.com/MarekKnapek/mk_crypto/blob/refactor/fuzz/mk_mac_hmac_fuzz.c

14
S obnovou nepomůžu, ale poradím pro příště:

Abych mohl obnovit soubor, který jsem omylem smazal, používám funkci Windows Shadow Volume. V Linuxu by byl ekvivalent BTRFS nebo ZFS copy on write snapshot. Přidal jsem si naplánovanou úlohu, která se spouští jednou denně. Obnova pak probíhá z okna vlastností složky, je tam karta předchozí verze. Nemusím instalovat žádný nový program, stačí jednou nastavit a už na to nemusím myslet, funguje to automagicky samo od sebe.

15
Citace
zejména pokud je CRT linkována dynamicky (což je asi jediný legální způsob)

Není. Volba překladače /MT (případně /MTd) zajistí statické linkování CRT. To je důležité například když chcete distribuovat svou aplikaci jako jediné .exe bez dalších závislostí, které by se musely doinstalovávat (redist).

Stran: [1] 2