neprihlásený Piatok, 26. apríla 2024, dnes má meniny Jaroslava
Zraniteľnosť OpenSSL Heartbleed bola zneužívaná minimálne od novembra

Značky: HeartbleedOpenSSLbezpečnosťútokyhackovanie

DSL.sk, 11.4.2014


Extrémne kritická zraniteľnosť Heartbleed v knižnici OpenSSL implementujúcej protokol SSL pre zabezpečený prenos dát bola zrejme známa a zneužívaná minimálne od novembra.

Tvrdí to Terrence Koeman z MediaMonks, ktorý má podľa svojich informácií pre Arstechnica a najmä organizáciu EFF k dispozícii logy paketov zo svojich testovacích serverov preukazujúce snahu o detekovanie prítomnosti zraniteľnej verzie OpenSSL respektíve priamo útoky už v novembri 2013.

Informácie o kritickej zraniteľnosti v knižnici OpenSSL, označovanej menom Heartbleed, boli zverejnené v utorok. Zraniteľnosť bola objavená v predchádzajúcich týždňoch, viaceré veľké internetové služby boli na ňu upozornené v dňoch pred zverejnením informácií.

Chyba prítomná vo verziách OpenSSL od marca 2012 umožňuje útočníkovi získať z pamäte zariadenia realizujúceho druhú stranu SSL spojenia 64 KB susediacich s dátovými štruktúrami použitými na spracovanie tzv. heartbeat požiadaviek pri útoku a potenciálne obsahujúcich citlivé dáta spracúvané procesom využívajúcim OpenSSL. Útok, ktorý nezanecháva stopy v štandardných logoch, je možné opakovať a potenciálne tak získať podstatnú časť pamäte daného procesu.

Napríklad v prípade webového servera poskytujúceho zabezpečené stránky je cez zneužitie chyby potenciálne možné získať jednak privátne kľúče k SSL X509 certifikátu stránok ale napríklad aj prihlasovacie údaje minimálne ostatných užívateľov aktuálne sa prihlasujúcich na stránky a obsah stránok zobrazovaných týmto užívateľom.

Heartbeat rozšírenie umožňuje jednej strane SSL spojenia zaslať druhej strane požiadavku na okamžitú odpoveď, za účelom udržania spojenia respektíve overenia jeho funkčnosti. Odosielateľ posiela v požiadavke dáta ľubovoľnej veľkosti do maximálne 64 KB, pričom druhá strana má ako odpoveď zaslať tieto dáta naspäť.

Chyba v OpenSSL spočíva v absencii kontroly odosielateľom uvádzanej veľkosti zaslaných dát a skutočnej veľkosti zaslaných dát. Keď tak útočník poslal v skutočnosti iba jeden bajt ale v hlavičke uviedol zaslanie 64 KB, zraniteľná verzia nakopírovala do odpovedacieho paketu 64 KB dát z pamäte susediacej s umiestnením spracovávanej správy s požiadavkou.

Koeman, ktorý si z neznámych dôvodov logoval pakety SSL spojení na svoje servery, v týchto logoch z novembra identifikoval takéto heartbeat správy, ktoré mali uvedenú deklarovanú veľkosť zasielaných dát väčšiu ako skutočné množstvo zaslaných dát. Správy tak zrejme slúžili na detekciu prítomnosti zraniteľnej verzie OpenSSL alebo priamo útoky.

Podľa informácií pre EFF útoky prichádzali z dvoch IP adries 193.104.110.12 a 193.104.110.20, ktoré sú podľa EFF zároveň súčasťou botnetu logujúceho komunikáciu na Freenode a ďalších IRC sieťach.


      Zdieľaj na Twitteri



Najnovšie články:

V bezplatnom DVB-T bude počas MS v hokeji aj Joj Šport
NASA komunikovala laserom na stovky miliónov km rýchlosťou 25 Mbps
Let vesmírneho Boeingu by sa už mal uskutočniť, o menej ako dva týždne
Vydané Ubuntu 24.04 s dlhou podporou
Uvedený notebook používajúci nový formát menších pamäťových modulov CAMM2
Nová verzia Windows 11 bude vyžadovať CPU s podporou ďalších inštrukcií, nepobeží na starších CPU
Google opäť odložil vypnutie cookies tretích strán v Chrome
HDD zdražia, Western Digital a Seagate to už oznámili veľkým zákazníkom
Po oprave zariadení v EÚ sa predĺži záruka a výrobcovia budú povinní opravovať aj po záruke
Japonská sonda nebola skonštruovaná aby prežila noc na Mesiaci, funguje aj po tretej


Diskusia:
                               
 

I riekol pán: "Veru veru hovorím Vám, blahoslavení nezašifrovaní, lebo ich je kráľovstvo nebeské. Lebo neviete dňa ani hodiny ajhľa príde pán domu a rozšifruje všetko!"
Odpovedať Známka: 9.4 Hodnotiť:
 

Amen

Ako sa dajú odstrániť z Windowsu tie hlášky o nebezpečnosti šifrovaného spojenia po vyťukani https?


Odpovedať Známka: -2.5 Hodnotiť:
 

neviem presne co mas na mysli, ale odporuca sa vymazanie vsetkych klucov (keyring). neviem ako sa to robi vo windowse, v linuxe je to jeden adresar.

za druhe, niektore stranky tiez menili certifikaty (napriklad websupport) a teraz si prehliadac vyhadzuje hlasky na import nveho kluca (hoci nechapem co vo websupporte treba manualne importovat ked by mali byt podpisany CA ktoru browser akceptuje).

za tretie, mozes mat len nejake spojenia na https strank co idu cez http (pludiny, iframy, reklamy atd) a vtedy hazde hlasku, ze niektore info je nezabezpecene
Odpovedať Známka: 5.0 Hodnotiť:
 

Do prehliadača napíšeš adresu s https, napríklad https://www.microsoft.com/ . Vo Windowse naskočí okno, že ide o nebezpečnú stránku a či chceš pokračovať. Treba tri krát kliknúť aby sa stránka zobrazila. Mnohých to odradí túto stránku navštevovať. Ako sa dá to dialógové okno vypnúť? Asi niekde v ovládacích paneloch.
Odpovedať Známka: 2.0 Hodnotiť:
 

Nemas nahodou zly datum na pc? Skus nastavit aktualny datum

Odpovedať Známka: 10.0 Hodnotiť:
 

tiez si myslim, ze to to bude zlym datumom na PC. Na zmenu certifikatu prehliadac neupozrnuje (iba na neplatnost), bezne certifikaty exspiruju a su vydavane nove a menene na serveroch... to by bolo zybytocne kedze tak ci tak certifikat je platny.

Ine je potrebe upozornovat pri pripajani na ssh tunel ze certifikat (verejne kluce) cieloveho servera boli zmenene... tam to ma vyznam... poss. MITM attack
Odpovedať Hodnotiť:
 

tu

http://dopice.sk/99d
Odpovedať Hodnotiť:
 

Toto je vysvetlenie, ktore pochopi aj vasa stara mama: http://xkcd.com/1354/
Odpovedať Známka: 9.3 Hodnotiť:
 

Ďakujem, Janíčko môj.
Odpovedať Známka: 10.0 Hodnotiť:
 

tazko ked nevie po anglicky
Odpovedať Známka: 6.0 Hodnotiť:
 

a hla! krasy a vyhody otvoreneho kodu!

kde sa hrabe zly, uzavrety kod, do ktoreho ma pristup len par vyvolenych ludi, kde je vsetko dokonale preverene a kde vsetko funguje tak ako ma...
Odpovedať Známka: -8.8 Hodnotiť:
 

heh pan je optimista
Odpovedať Známka: 10.0 Hodnotiť:
 

A poriadny optimista :). Podla jeho zmyslania su Windows updaty nepotrebne.
Odpovedať Známka: 2.0 Hodnotiť:
 

niekto kto tomu rozumel ??... ako môže aplikácia bez vedomia programátora robiť toto :

"zraniteľná verzia nakopírovala do odpovedacieho paketu 64 KB dát z pamäte susediacej s umiestnením spracovávanej správy s požiadavkou."

aspoň to mala XORnúť a bol by pokoj
Odpovedať Známka: -4.3 Hodnotiť:
 

jednoducho...
prijmes paket, ulozis si ho do pamate. Zostavujes paket s odpovedou, z povodneho si precitas velkost dat, ktore mas poslat naspat a zacnes ich kopirovat z povodneho paketu do noveho.
No a co ze v povodnom tych dat tolko nebolo :) skopiruje sa to co v pamati nasleduje za nim.
Chyba je samozrejme v tom, ze si si na zaciatku neskontroloval, ci udavana velkost dat suhlasi so skutocne prijatym paketom.
Odpovedať Známka: 10.0 Hodnotiť:
 

preco by bol po xorovani pokoj? a vobec, co to trepes za nezmysly? ak tomu nerozumies, pekne ticho suchaj nohami a nestrapnuj sa...
Odpovedať Hodnotiť:
 

Ak by to bolo spomenute iba raz, tak to zoberiem ako pekny pokus o ironiu, ale takto to skor beriem ako diletanstvo zo strany autora spravicky. (HINT: heartbeat vs. heartbleed)
Odpovedať Známka: -10.0 Hodnotiť:
 

heart beat je tá odpoved či spojenie žije
Odpovedať Známka: 10.0 Hodnotiť:
 

heartbeat je extension pre openssl
heartbleed je zranitelnost v nom.
Odpovedať Známka: 10.0 Hodnotiť:
 

ano, a kedy a zacnu predavat tie tricka z krvacajucim srdcom? dobra ironia heartbeat... heartbleed
Odpovedať Známka: 0.0 Hodnotiť:
 

Hehehe, to je moj kolega :) Pozeram jak puk, ze co to :)
Odpovedať Známka: 10.0 Hodnotiť:
 

Takže by som mal asi vymeniť zopár hesiel..
Odpovedať Známka: 10.0 Hodnotiť:
 

len si daj pozor odkial ich budes menit, aby nechytali prave tieto :-P
Odpovedať Známka: 6.0 Hodnotiť:
 

Tak hádam som použil zabezpečené pripojenie.
Inak je to celkom fuška, všetko pomeniť, otestovať, potriediť v keepassx, vymazať dávno zabudnuté účty...
Odpovedať Známka: -3.3 Hodnotiť:
 

1) Ja len nerozumiem tomu poreco rozsirenie heartbeat bolo implementovane ako bolo... teda este je. V principe ide o keep-alive. Preco moze klient poslat cokolvek do 65kB a to iste ma dostat spat? Nestacilo pre overenie ci spojenie existuje odoslat len jeden bajt a ten isty dostat spat? Nemohlo by sa stat to co sa stalo.

2) Pripajam zaujimave veci
- autorom commitu s rozsirenim aj fixom je Dr. Stephen Henson

- osudny commit zo dna (a pozor kedy!) 1.1.2012 o 00:59 (ano, na silvestra!): http://goo.gl/8tZNxU

- commit s fixom zo dna 7.4.2014: http://goo.gl/zyx9wB

V podstate cely fix je v par riadkoch kodu (overenie hranic):
if (1 + 2 + payload + 16 > s->s3->rrec.length)
return 0; /* silently discard per RFC 6520 sec. 4 */

Odpovedať Známka: 7.5 Hodnotiť:
 

este RFC pre heartbeat:
https://tools.ietf.org/html/rfc6520#section-4
Odpovedať Známka: 10.0 Hodnotiť:
 

Lubovolny paket do 65kB je tam na MTU discovery. Na tejto vrstve by to nemalo byt treba, ale dali tam tu moznost.

Malokto pocita pri navrhu s tym, ze bude v implementacii diera. Keby sa malo navrhovat s tym, ze to niekto zle naimplementuje, tak sa nemoze navrhnut nic.
Odpovedať Známka: 10.0 Hodnotiť:
 

Na tejto vrstve sa nema co zistovat MTU. "Pingovat" 65k by som nedovolil ani po lokalnej sieti a nie to cez internet. Vsade su statistiky ako rastie z roka na rok vytazenie uzlov / chrbticovych sieti - nikto ale neuvadza kolko z toho je realny narast informacneho toku a kolko je komunikacny overhead.

napr. cloveka co prisiel v minulosti s napadom posielat binarne data zakodovane ako base64 string by som dal lyncovat na namesti.
Odpovedať Známka: 6.7 Hodnotiť:
 

> Na tejto vrstve sa nema co zistovat MTU

To je prave otazka. Vyssie som pisal, ze by to nemalo byt treba. Ina vec je, ze ked je program schopny to zistit, tak dokaze komunikovat efektivnejsie uz len tym, ze pripravuje pakety, ktore nemusia byt fragmentovane. A pri "vrstve naviac", akou je SSL, sa usporeny cas vzdy hodi.

Vo vseobecnosti - vrstvy su dobra vec, ale niekedy sa hodi ich obchadzat. Clovek si povie, ze by aplikacnu vrstvu nemalo zaujimat nic mimo vrstvu pod nou. Ale potom si uvedomi, ze uzivatel by sa od OS rad dozvedel, ze si vykopol kabel (fyzicka vrstva). Alebo niekedy sa aplikacii hodi vediet svoju IP, aby podla nej vybrala najlepsiu "druhu stranu".

> "Pingovat" 65k by som nedovolil ani po lokalnej sieti a nie to cez internet.

Ak myslis "take domace pinganie", tak tam to velmi nedava vyznam. Ak to posles s priznakom DNF (alebo pingas na IPv6), potom to uz moze davat vyznam. Napr: pri uvahe "preco miestami pada spojenie?" alebo na vacsej sieti "nestoji jumbo ramcom nieco v ceste?"
Odpovedať Hodnotiť:
 

Ja velmi dobre viem ako je to s tym zistovanim MTU myslene.
Noze, pripojenie akou technologiou pre koncovych pouzivatelov pouzivanou DNES podoruje MTU aspon radovo porovnatelne so spominanym limitok 65k?
Inak... kto povedal, ze 2 po sebe nasledujuce TCP pakety pojdu rovnakou cestou k cielu? "Jaj, no hej to je vlastne pravda" by pravdepodobne znela odpoved predkladatela keby bo konfrontovany takou otazkou - a uz je nasa "optimalizacia" v p***.
Uz som mal "tu cest" neveriaco krutit hlavou pri implementacii nejedneho protokolu "podla specifikacie niecieho mokreho sna". Dych mi vyrazilo vsak az kodovanie binarnych dat ako ascii hexa kod > t.j. 100% overhead
Odpovedať Známka: 5.0 Hodnotiť:
 

Na tom, ci su alebo nie su take technologie az tak velmi nezalezi. Ak je MTU navrhom obmedzene na 65k, tak mi nedava zmysel vymyslat si iny limit specialne pre tento ucel, ktort by neskor nemusel stacit. To su zbytocne starosti naviac.

Spominany limit je nie nahodou zapisatelny ako 2B, takze sa nikto o nic nestara, len to precita. 1B by dal limit 255, co je na dnesne siete malo.

Takze navrhujes pridelit nieco ako 11b a zlozito to odtial vytahovat, byt umyselne nekompatibilny s novsimi technologiami a v podstate nic neziskat? (na zapis 11b budu stale treba 2B)
Odpovedať Hodnotiť:
 

Ze "zlozito" vytahovat... Ok zasmiali sme sa. Kto neovlada bitove operacie tak nech radsej nestrka ruky do navrhu ani implementacie komunikacnych protokolov.

Cele je to ale o tej istej veci ako nedavny problem s goto v overovani SSL v Apple systemoch. Nieco taketo nemohlo prejst serioznym code review. odliadnuc od toho ze staticka analyza kodu nieco take nedovoli (unreachable code pri goto)

Zaradit memcpy operaciu pri spracovani poziadavky klienta s parametrom size (count) KTORY MI ON POSLAL > tak to je vazne na zamyslenie. Totalne diletantska robota pri implementacii. Ak sa niekomu nechce explicitne kontrolovat kazdu takuto spravu, tak nech si laskavo napise 2 kilobajtovu kniznicu na "safe array" a vsetky datove operacie ktore bude dana trieda vystavovat vnutri osetri.

Po code reviews a tyzdnovom opakovanom odmietani commitu lebo dotycny nebol v stave vsade posunut hodnotu o jeden bit vsak viem, ze o takychto programatorov nie je nudza.
Odpovedať Hodnotiť:
 

"Nieco taketo nemohlo prejst serioznym code review."

Clovek nie je pocitac a vela chyb prehliadne (naviac je ho mozne peniazmi alebo silou prinutit, aby sa az tak dobre nepozeral).

"Zaradit memcpy operaciu pri spracovani poziadavky klienta s parametrom size (count) KTORY MI ON POSLAL [...] Totalne diletantska robota pri implementacii."

Mohla to byt aj klasicka chyba. Este stale ide aj o vykon a duplicitne kontroly sa zvyknu v niektorych projektoch vyhadzovat (inde sa menia na asserty, co by tu nic nezmenilo). A ked tam nahodou bola povodne kontrola 2x, 1 vyhodil jeden clovek, druhu druhy, neskontrolovany merge a mame to.

"nech si laskavo napise 2 kilobajtovu kniznicu na "safe array" a vsetky datove operacie ktore bude dana trieda vystavovat vnutri osetri."

Myslim, ze toto nemaju prave kvoli tomu vykonu. A ostatne, keby si uvedomili, ze tam je chyba, tak by si to osetrili aj tak.
Odpovedať Hodnotiť:
 

Koli vykonu? Tak moment.
Bavime sa o sifrovanom spojeni, cez ktore sa najcastejsie posielaju informacie v textovej podobe a niekto tu ide riesit "vykonovy dopad" primitivneho volania (ne)virtualnej fukcie v ktorej je podmieneny skok?
Som jediny komu to pripada trochu postavene na hlavu? Je to nemeratelny rozdiel.

"Clovek nie je pocitac a vela chyb prehliadne (naviac je ho mozne peniazmi alebo silou prinutit, aby sa az tak dobre nepozeral)."
A preto tu mame take nepotrebne hluposti, ktore su len pre amaterov - Unit testy & Integracne testy.
Prave ma napadlo, ze (Microsoftacky) C++ AMP, na ktory robi vlastnu implementaciu tolko ludi / skupin, ze ich mozes zratat na jednej ruke ma Conformance test suite.

Ak je to vsak pripad s peniazmi, ktory spominas, tak s tym sa vela robit neda - len "zaliezt na stromy". A vlastne preco tu stracame cas lamentovanim nad profesijnou neschonostou alebo az prilis dobrou schopnostou odrbavat druhych, ked my sme ti poskodeni.
Odpovedať Hodnotiť:
 

"Som jediny komu to pripada trochu postavene na hlavu? Je to nemeratelny rozdiel."

Deje sa to viackrat, takze je rozdiel sice maly, ale zanedbatelny.
Ked sa ale pozries na zdrojaky OpenSSL, tak uvidis, ze tam lovia aj velmi drobne casy. Pozri sa na ich nahradu malloc a free (tiez za cenu bezpecnosti).

"Unit testy & Integracne testy."

To u najcastejsieho opensource modelu vyvoja velmi nefunguje a asi ani nemoze fungovat. Ked si unittesty robi sam vyvojar, tak je to zle a nebude to dobre fungovat (uz len preto, ze kod pozna). A druhy to asi robit nebude...
Pri TDD je to este horsie - spravia sa testy, podla nich sa to naprogramuje, ale coverage sa uz vacsinou neriesi.

Pre vetu o C++ AMP sa mi v hlave nepodarilo postavit syntakticky strom, takze neviem, ako na nu reagovat.
Odpovedať Hodnotiť:
 

C++ AMP je rozsirenie jazyka C++ o podporu vykonavania paralelizovatelneho kodu na GPU. Existuje k nemu otvorena specifikacia a Test suite na overenie, ci "dotycny docital specifikaciu do konca a a aj spravne pochopil" - a to sa nejedna o nijak kriticku funkcionality, ktoru rozsirenie poskytuje. Je to tak specificka vec, ze vlastnu implementaciu robi "dva a pol" cloveka. Preco nieco take nemoze existovat aj pre ine specifikacie, ktore su navyse nasadene tak globalne, ze len malokto s nimi neprisiel do kontaktu?
Odpovedať Hodnotiť:
 

"Ci spravne pochopil" sa principialne neda otestovat. Da sa otestovat, ci tam nie su pouzivane nejake explicitne zakazane postupy - pri Turingovsky uplnych programovacich jazykoch sa dost neda otestovat, ci to bude spravne fungovat.

Nech ideme lubovolne hlboko, mozeme sa dostat k formalnej verifikacii, ale tam je zase ten problem, ze velmi formalny zapis je v podstate uz len ine naprogramovanie programu, kde sa daju rovnako spravit chyby.
Odpovedať Hodnotiť:
 

AD byt nekompatibilny - ziadna nekompatibilita by sa nekonala, len optimalizacia by koncila pri nizsej hodnote.
Aka ze to technologia bude v domacnostiach dominantna napr. v roku 2020 ze budeme potrebovat "optimalizovat" po 65k framy? Ak ma mat nieco dominanciu v sietovych prvkoch pre koncakov o 6 rokov, musi sa jednat uz o existujucu technologiu. Do toho roku vyjde minimalne jedna revizia TLS - tam nech si to potom pridaju do specky.
Odpovedať Hodnotiť:
 

"AD byt nekompatibilny - ziadna nekompatibilita by sa nekonala, len optimalizacia by koncila pri nizsej hodnote."

To zase zavadza overhead, ktoremu si sa chcel vyhnut. Takze usetrime 5 bitov v parkrat poslanom pingu (teda uspora v praxi ziadna, lebo 3 bity sa prenasaju dost zle same), ale vdaka tejto "optimalizacii" budeme niekedy pri beznej a ovela castejsej komunikacii posielat o 64 bajtov hlaviciek naviac.

Aby toho nebolo malo, tak to zavedieme s tym, ze v dalsej revizii to bude mozno len s usetrenim 4 bitov a bude pre to treba dalsia implementacia. A potom mozno dalsia spec s usetrenim 3 bitov.

Ako vidim, tak to ma same vyhody ;-).
Odpovedať Hodnotiť:
 

o akom setreni bitov pises? Normalne by sa pouzivalo napr 12 bitov zo 16 s tym ze zbytok (4) je v tejto verzii protokolu oznaceny ako RESERVED - a uz mas zabezpecenu strukturalnu kompatibilitu s buducou verziou kde mozes expandovat az do hodnoty 65k. Aby bola keepalive paketu umoznena payload velkost 65k je trochu odveci, nemyslis?

Len tak mimochodom, "setrenie" o ktorom sa tu pise na zaklade vyhodnocovania MTU je mozny len ak je vypnuty Nagle algoritmus. Z ktorej strany tecie viac dat? Od klienta alebo ku klientovi? Zrejme ku klientovi, nie? To web servery / web services bezne mavaju Nagle vypnuty?
Odpovedať Hodnotiť:
 

Ok, mas strukturalnu kompatibilitu, ale prakticky nic neusetris; normalne by sa este hodilo naviac robit nejaky bitand podla verzie protokolu. Naviac si musis vycucat z prstu nejaky pocet bitov, ktory bude stacit.

A potom pridu jumbo packety, kompletna podpora novej verzie TLS nedohladne (kto by kvoli podpore uplne inej vrstvy aktualizoval nieco uplne mimo?) a mame problem. A preco? No lebo sa niekto chcel poistit, aby aplikacia nepodpovedala na paket o velkosti 65k...

Toto mi skor pride ako optimalizacia "v nasej firme mame prvy oktet IP adries vzdy rovnaky, tak si implementujme siet tak, aby to bolo "reserved" (alebo aby sa vobec neposielal)."
Mozno sa tym usetri zanedbatelne mnozstvo dat od utocnikov, ale vyrazne sa znarocni vsetko ostatne.
Odpovedať Hodnotiť:
 

> napr. cloveka co prisiel v minulosti s napadom posielat binarne data zakodovane ako base64 string by som dal lyncovat na namesti.

Nesuvisi s temou, ale aj tak: ak protokol podporuje len text, tak je base64 asi najjednoduchsia cesta, ako ho rozsirit na binarky a byt pri tom spatne kompatibilny. Alebo co lepsie by si navrhol ty?
Odpovedať Hodnotiť:
 

v prvom rade sa nemaju co binarne subory posielat textovym protokolom. Ja mam dost ked vidim boolean posielat ako 4 bajtovy integer a nie to este ako poondiaty text.
Odpovedať Známka: 5.0 Hodnotiť:
 

Niekto hlada dovody, preco to uzivatelom nedovolit a niekto najde hack, ako to moze fungovat na niecom funkcnom a overenom.
Uzivatelia si vybrali...
Odpovedať Hodnotiť:
 

ano a potom znacna cast trafficu internetom ma overhead 30 - 40%. Patrim medzi osoby, ktore by sa neuspokojili s takym navrhom - proste "nemohol by som spavat"
Odpovedať Známka: 3.3 Hodnotiť:
 

Znacna cast? Toho 0,00nic%?

Unicode ta nestve? Tiez velmi neefektivny, ked mame narodne znakove sady. A aj tie su neefektivne, kedze cast z nich nepouziva vacsina ludi. A co vetna konsteukcia? Keby sme pouzivali slovnik, tak sme schopni zapisat kazde slovo v zakl. tvare na nieco ako 2B. A keby sme zaviedli substituciu pre cele myslienky, tak by asi ziadny text neprekrocil jednotky bajtov.

Mas moznost robit prenosy inak, ako to robi kazdy rozumny clovek. Naviac mas moznost bouncnut maily s prilohami... He to na tebe.
Odpovedať Hodnotiť:
 

AD slovnik - ale ved to sa prave pouziva hovori sa tomu bezstratova kompresia - v pripade textu referuj priamo na Deflate.
Skusal si vsak uz pakovat base64?
Odpovedať Hodnotiť:
 

Prakticky vsetka bezstratova kompresia textu dneska si so sebou nesie zbytocny overhead - nejaka tabulka s prefixami / "slovami" / textom. Preco ju nemat vsade spolocnu? (Myslim len pre zrozumitelny text)

Base64 sa da pakovat, aj ked to nie je ako textovy original (co dava zmysel). Skusal som to na jednom paperi (pdf text s par obrazkami), ktory by mal byt aspon nejak komprimovatelny. Original velkost 756458 B, po spakovani (7z) 694911 B.
Base64 velkost 1021884 B, po spakovani 718785 B.

Takze to vyzera tak, ze ovela vacsi problem ako base64 je prenos nepakovanych dat.
Odpovedať Hodnotiť:
 

Ale to co si popisal nema hlavu a patu. Ako base64 sa prenasaju binarne subory preto lebo su "binarneho" charakteru nie preto, ze niekto si robi srandu a koduje text do base64.
Ako base64 "tecu" zip-y a framy videa.

Skus to takto:
1 MB textu > kompresia
vs.
0.75MB random dat > base64 (1MB) > kompresia
Odpovedať Hodnotiť:
 

Neviem, co tym chces povedat.

Kedze bolo pisanych 0.75MB a nie MiB, tak pouzivam zaklad jednotiek 1000.

1MB (1000000 B) nahodneho textu > kompresia (763371 B)
vs.
750000 B nahodnych dat > base64 (1013158 B) > kompresia (779014 B)
Kompresia nahodnych dat bez base64 > 760396 B.

Stale to vyzera tak, ze to nezabija base64...
Odpovedať Hodnotiť:
 

vam tu nejebe ???
Odpovedať Známka: 5.0 Hodnotiť:
 

tu

http://dopice.sk/99d
Odpovedať Hodnotiť:

Pridať komentár