<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: Criptografie</title>
	<atom:link href="http://trilema.com/2010/criptografie/feed/" rel="self" type="application/rss+xml" />
	<link>http://trilema.com/2010/criptografie/</link>
	<description>Moving targets for a fast crowd.</description>
	<pubDate>Wed, 13 May 2026 22:23:31 +0000</pubDate>
	<generator>http://polimedia.us</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: cipslim</title>
		<link>http://trilema.com/2010/criptografie/#comment-14264</link>
		<dc:creator>cipslim</dc:creator>
		<pubDate>Sun, 31 Jan 2010 06:02:43 +0000</pubDate>
		<guid isPermaLink="false">http://trilema.com/?p=4487#comment-14264</guid>
		<description>E mult mai avantajoasa incriptarea pe imagine, cea de sunet daca o modifici prea mult se poate detecta tehnologic ca anomalie in momentul transmisiei. Si ce tot ziceti acolo ca mai mult de 20KHz nu se pot pune deoarece omul nu aude peste 18 k decat cand e sub 10 ani. Cea cu pozele este mult mai avantajoasa, datorita numarului masiv de imagini care circula in toate directiile.</description>
		<content:encoded><![CDATA[<p>E mult mai avantajoasa incriptarea pe imagine, cea de sunet daca o modifici prea mult se poate detecta tehnologic ca anomalie in momentul transmisiei. Si ce tot ziceti acolo ca mai mult de 20KHz nu se pot pune deoarece omul nu aude peste 18 k decat cand e sub 10 ani. Cea cu pozele este mult mai avantajoasa, datorita numarului masiv de imagini care circula in toate directiile.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dadatroll</title>
		<link>http://trilema.com/2010/criptografie/#comment-14261</link>
		<dc:creator>dadatroll</dc:creator>
		<pubDate>Sun, 31 Jan 2010 03:43:19 +0000</pubDate>
		<guid isPermaLink="false">http://trilema.com/?p=4487#comment-14261</guid>
		<description>Nu stiu ce sa zic. Sexul cu mana nui mai bun decat alalalt. Parerea mea.</description>
		<content:encoded><![CDATA[<p>Nu stiu ce sa zic. Sexul cu mana nui mai bun decat alalalt. Parerea mea.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: spyked</title>
		<link>http://trilema.com/2010/criptografie/#comment-14231</link>
		<dc:creator>spyked</dc:creator>
		<pubDate>Sat, 30 Jan 2010 21:06:03 +0000</pubDate>
		<guid isPermaLink="false">http://trilema.com/?p=4487#comment-14231</guid>
		<description>&lt;blockquote&gt; Tot ce conteaza e numarul de octeti in fisier si numarul de octeti in mesajul din el, pentru a calcula adevarata proportie filler/message.&lt;/blockquote&gt;
Na, păi exact în sensul ăsta densitatea aia de informație contează. Doar că tu ai luat o imagine de 1024x768 ca punct de reper, iar eu o melodie de câteva minute, să zicem 3, cam cât au multe melodii în ziua de azi. 3*60*44100*2 caractere (cam 15MB), ăsta-i filler-ul cu tot cu mesajul util. Acum câți octeți poți să bagi fără să distrugi semnalul audibil, dacă folosești modulare în amplitudine sau în fază sau dacă codezi direct mesajul în octeți, asta-i deja o cu totul altă discuție.

Problema aici e că e destul de greu de ascuns informația în părțile relevante ale înregistrării (aici deja nu mă mai refer la fișierul în sine, ci la sunet) fără să o faci praf. Dar asta depinde mult de caracteristicile înregistrării în cauză: nivelul mediu al volumului din fișier, banda de frecvență acoperită și așa mai departe. De asemenea, ar trebui luat în calcul dacă s-ar putea face asta într-un mod destul de eficient într-o transmisie în timp real, de exemplu (mă refer la Skype &#38; co.), factorii de mai sus (tipuri de codificare: cam care-i probabilitatea să își dea seama cineva că e folosit Manchester diferențial, de exemplu), și foarte important, cât de tare îmi doresc eu să fie criptarea în cauză (la fel de bine pot să consider că e de ajuns pentru mine să folosesc tehnica cu armonicele, în ideea că sunt destul de slabe șansele să bage careva un FFT tocmai unde m-am hotărât eu să fac prostii).

Totuși, ceva îmi spune că e ceva și de capul criptografiei analogice (chit că mă depășește în momentul ăsta) și probabil există ceva mai avansat decât decodoarele HBO în domeniu. Până acolo, ideea în sine mi se pare interesantă.</description>
		<content:encoded><![CDATA[<blockquote><p> Tot ce conteaza e numarul de octeti in fisier si numarul de octeti in mesajul din el, pentru a calcula adevarata proportie filler/message.</p></blockquote>
<p>Na, păi exact în sensul ăsta densitatea aia de informație contează. Doar că tu ai luat o imagine de 1024x768 ca punct de reper, iar eu o melodie de câteva minute, să zicem 3, cam cât au multe melodii în ziua de azi. 3*60*44100*2 caractere (cam 15MB), ăsta-i filler-ul cu tot cu mesajul util. Acum câți octeți poți să bagi fără să distrugi semnalul audibil, dacă folosești modulare în amplitudine sau în fază sau dacă codezi direct mesajul în octeți, asta-i deja o cu totul altă discuție.</p>
<p>Problema aici e că e destul de greu de ascuns informația în părțile relevante ale înregistrării (aici deja nu mă mai refer la fișierul în sine, ci la sunet) fără să o faci praf. Dar asta depinde mult de caracteristicile înregistrării în cauză: nivelul mediu al volumului din fișier, banda de frecvență acoperită și așa mai departe. De asemenea, ar trebui luat în calcul dacă s-ar putea face asta într-un mod destul de eficient într-o transmisie în timp real, de exemplu (mă refer la Skype &amp; co.), factorii de mai sus (tipuri de codificare: cam care-i probabilitatea să își dea seama cineva că e folosit Manchester diferențial, de exemplu), și foarte important, cât de tare îmi doresc eu să fie criptarea în cauză (la fel de bine pot să consider că e de ajuns pentru mine să folosesc tehnica cu armonicele, în ideea că sunt destul de slabe șansele să bage careva un FFT tocmai unde m-am hotărât eu să fac prostii).</p>
<p>Totuși, ceva îmi spune că e ceva și de capul criptografiei analogice (chit că mă depășește în momentul ăsta) și probabil există ceva mai avansat decât decodoarele HBO în domeniu. Până acolo, ideea în sine mi se pare interesantă.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mircea Popescu</title>
		<link>http://trilema.com/2010/criptografie/#comment-14223</link>
		<dc:creator>Mircea Popescu</dc:creator>
		<pubDate>Sat, 30 Jan 2010 20:09:43 +0000</pubDate>
		<guid isPermaLink="false">http://trilema.com/?p=4487#comment-14223</guid>
		<description>Nu conteaza "densitatea de informatie" asa cum o definesti tu, tot asa cum nu-i relevant daca bmp-ul respectiv va fi afisat pe un monitor de 24 de inch sau pe un ecran de iphone. Tot ce conteaza e numarul de octeti in fisier si numarul de octeti in mesajul din el, pentru a calcula adevarata proportie filler/message.

Teoria cu cine-i mai sensibil, ingineru' de sunet sau prelucratoru' de imagini e inutila, pentru ca toti pixelii descriu ceva vizibil, in timp ce nu toata informatia de sunet descrie ceva audibil. Ca rezultat, exista parti mai relevante si parti mai putin relevante intr-o inregistrare, dar nu intr-o fotografie. Daca tu ascunzi informatia doar in partile mai putin relevante din inregistrare, slabesti de fapt calitatea encriptarii.</description>
		<content:encoded><![CDATA[<p>Nu conteaza "densitatea de informatie" asa cum o definesti tu, tot asa cum nu-i relevant daca bmp-ul respectiv va fi afisat pe un monitor de 24 de inch sau pe un ecran de iphone. Tot ce conteaza e numarul de octeti in fisier si numarul de octeti in mesajul din el, pentru a calcula adevarata proportie filler/message.</p>
<p>Teoria cu cine-i mai sensibil, ingineru' de sunet sau prelucratoru' de imagini e inutila, pentru ca toti pixelii descriu ceva vizibil, in timp ce nu toata informatia de sunet descrie ceva audibil. Ca rezultat, exista parti mai relevante si parti mai putin relevante intr-o inregistrare, dar nu intr-o fotografie. Daca tu ascunzi informatia doar in partile mai putin relevante din inregistrare, slabesti de fapt calitatea encriptarii.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: spyked</title>
		<link>http://trilema.com/2010/criptografie/#comment-14221</link>
		<dc:creator>spyked</dc:creator>
		<pubDate>Sat, 30 Jan 2010 19:54:02 +0000</pubDate>
		<guid isPermaLink="false">http://trilema.com/?p=4487#comment-14221</guid>
		<description>Inginerii de sunet sunt sensibil mai puțini decât cei care prelucrează imagini (specialiști sau nu). În sensul că destul puțini indivizi o să stea să analizeze o bucată de sunet să observe asta. Dar fiindcă argumentul ăsta s-ar putea să nu te convingă: mergând pe ideea conform căreia densitatea informației e mult mai mare la sunete (44.1 kHz 16 bit =&#62; 1/44100 secunde pentru 2 octeți deci pentru două caractere ASCII în cazul ideal - în realitate, pentru a compune conținutul cu o undă greu perceptibilă e nevoie de ceva mai mult de atât, hai să zicem ceva de ordinul câtorva milisecunde) decât la imagini, introducerea unui text în cadrul unui fișier .wav de câteva minute, cu șanse foarte mici de a fi găsit chiar în cazul analizei cu un program de editare, ar trebui să fie lipsită de riscuri.

Sau chiar alterarea directă a câtorva sample-uri, la fel ca și la imagini; un fel de Stairway to Heaven, fiindcă putem să punem textul și în ordine inversă, asta dacă are chef cineva să asculte mesaje ascunse, de data asta pe bune.</description>
		<content:encoded><![CDATA[<p>Inginerii de sunet sunt sensibil mai puțini decât cei care prelucrează imagini (specialiști sau nu). În sensul că destul puțini indivizi o să stea să analizeze o bucată de sunet să observe asta. Dar fiindcă argumentul ăsta s-ar putea să nu te convingă: mergând pe ideea conform căreia densitatea informației e mult mai mare la sunete (44.1 kHz 16 bit =&gt; 1/44100 secunde pentru 2 octeți deci pentru două caractere ASCII în cazul ideal - în realitate, pentru a compune conținutul cu o undă greu perceptibilă e nevoie de ceva mai mult de atât, hai să zicem ceva de ordinul câtorva milisecunde) decât la imagini, introducerea unui text în cadrul unui fișier .wav de câteva minute, cu șanse foarte mici de a fi găsit chiar în cazul analizei cu un program de editare, ar trebui să fie lipsită de riscuri.</p>
<p>Sau chiar alterarea directă a câtorva sample-uri, la fel ca și la imagini; un fel de Stairway to Heaven, fiindcă putem să punem textul și în ordine inversă, asta dacă are chef cineva să asculte mesaje ascunse, de data asta pe bune.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
