Nem a modszerek hianyoznak, hanem a bizalom. A DARPA az USA vedelmi miniszteriumanak kutatointezete. Emiatt nem csak a kulfodi, de meg az USA beli cegek sem fognak bizni abban amit a segitsegukkel krealnak. Az USA plutokracia, vagyis a milliardosok szabnak meg mindent, es a zsebukben van szinte az osszes politikus, donteshozo, akarmilyen szinben is indul.
Az a baj a világgal, hogy a hülyék mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.
Ezt nem teljesen értem. Ez miért jobb vagy több annál, mint ha maga a tároló (fájlrendszer - fscrypt, partíció vagy teljes eszköz - LUKS/dm-crypt) van titkosítva, és feldolgozáskor, vagyis olvasáskor és íráskor van transzparens módon kezelve?
a feldolgozást is titkosítva végzi el, de mindezt hardveresen gyorsítva, méghozzá úgy, hogy a feladatok megoldásának sebessége vetekedjen a nem titkosított adatok feldolgozásának teljesítményével
Ha a feldolgozás a titkosított, értelmezhetetlen adatokon történik, akkor miért kell rá hardveres gyorsítás, és miért lenne lassabb? Ha pedig ugyanúgy ki kell kódolni az adatot a feldolgozás egy szakaszában, akkor mitől előrelépés a jelenlegi megoldásokhoz képest? Szerintem nyilvánvalóan így is van visszafejtés, amit kiszerveznének ASIC-ra, majd onnan dolgozza fel a CPU. De ez mitől modernebb megoldás pl. a processzorokban levő AES-NI hardveres gyorsításnál?
<-ƘƘ->
Csak érintőlegesen, egyetemi képzés keretében foglalkoztam titkosítási kérdésekkel, de azokból úgy tudom, hogy már a módszerekkel is komoly fejfájások vannak.
A talán legnagyobb gond a reménybeli kvantumgépek alkalmazási szintű megjelenése, de akadnak matematikai bizonytalanságok is.
MaCS
Fán nem lehet motorozni, motoron viszont lehet fázni!
En sem ertem igazan. Adatokat feldolgozni csak titkositatlanul, kicsomagolva lehet, osszeallitva azt az adatszerkezetet, aminek ertelme van sot gyakran csak ugy ha a teljes "kep" (akarmi) egyszerre rendelkezesre all.
Esetleg ha az adatszerkezet nagyon egyszeru es eleve ugy tervezik meg, hogy ilyen modon lesz titkositva es a muveletek nagyon egyszeruek, elemi szintuek, vagy nem igenyelnek semmilyen komolyabb logikat, vagy hogy egyszerre lassak az osszetartozo adatokat... talan...de meg ott is ott van az a kerdes, hogy mit csinalnak a kapott eredmennyel?
Ugy el tudom kepzelni, hogy a bitek, vagy byteok onalloan egymastol fuggetlenul informaciot hordoznak.
Az a baj a világgal, hogy a hülyék mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.
Gondolom már a tervezési fázisban is benne van a.hátsó kapu...
If it is not broken then don't fix it!
Ha jól értem, akkor kb ilyesmi lehet:
Adott egy adat, ami legyen az egyszerűség kedvéért csak egy szám, az hogy 124. Ez a titkosítatlan adat. Adott egy adatfeldolgozó algoritmus, ami szintén az egyszerűség miatt legyen az, hogy 3-mal megszorozzuk. Tehát ugye a 124 feldolgozott eredménye 372. Tehát a feldolgozás egy lépésben van:
1. 124-en elvégezzük a feldolgozást (3-mal szorzás), 372 lesz.
Behozzuk a titkosítást, az algoritmus mindegy, a lényeg 124 titkosítva 263 lesz. A 372 titkosítva meg 178. Ilyenkor ugye a feldolgozás így módosul:
1. 263 megfejtése 124-re (mert titkosított formában kapjuk az adatot)
2. 124-en elvégezzük a feldolgozást (3-mal szorzás), 372 lesz.
3. 372 titkosítása 178-ra (mert titkosított formában továbbítjuk az eredményt)
Na most cikkben említett homomorf titkosítás ugyanazt csinálná mint fent, de egy műveletben, magán a titkosított adaton, és az eredmény is titkosított lesz:
1. 263-on elvégezzük a feldolgozást (???) és 178 lesz.
Itt nyilván a feldolgozás nem az eredeti művelet, azaz a 3-mal való szorzás, hanem valami más, hisz 263 * 3 az nem 178, hanem 789. 
Hogy pontosan mi ez a speciális feldolgozó algoritmus és hogyan jön létre, arról fogalmam sincs, de matematikailag valahogy megoldható. Viszont ugye probléma, hogy a speciális feldolgozó algoritmus baromi az lassú, erre lennének hardveres gyorsítók.
Ha jól értem. Lehet hülyeség, amit írtam.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
A lényeg, hogy találjunk valami nem létező problémát, amire lám már van is hardware-es megoldás. Hogy biztonságos-e? Hát hogyne, ez a kérdés fel sem merülhet; de gyors
Ehhez kepest az AMD prociknak nem esik nehezukre a memoriat titkositani on the fly, szoval nem erzem ezt az oriasi problemat amit megoldanak. Es azert a memoria eseten kicsit nagyobb savszelessegrol van szo, mint szutykos hattertaraknal.
Jah, végül is megoldható, mert elvégezhetjük közvetlen a titkosított, 263-as értéken is a szorzást, csak titkosítani kell a 3-ast is hozzá, hogy igazodjon, és végeredményként ugyanúgy a 178-at kapjuk. Habár ez még így is két lépés és nem egy, de akkor is előrelépés! Az ASIC meg ugye tehát akkor azért kell, hogy titkosítsa az elvégzendő műveleteket.
<-ƘƘ->
Solarwinds123 
Aki azt mondja "nem tudom elhinni az igazságot" az naiv. Aki azt mondja "nem akarom tudni az igazságot" az ostoba. Aki azt mondja "az igazság tilos" az gonosz. Aki azt mondja "én határozom meg az igazságot" az beteg.
Lehet hogy nem jol ertem amit irtal, de szerintem nem.
Elvileg ugy kell megszoroznod a valodi szamot, hogy csak a titkositott formajaban latod, es arrol sincs fogalmad hogy milyen modon titkositottak, ergo nem tudod semmilyen modon visszafejteni, de megis el tudod vegezni rajta a muveletet. Ez ugye eleg problemas, de a cikkbol ez jon le.
Ugy talan meg lehet megoldani, hogy a titkositast vegzo framework nem csak titkosit, de a titkositassal parhuzamosan egyfajta middleware apit is epit, a titkositott adathoz. Ki nem kodolja nekunk, de megadhatjuk neki, hogy milyen muveletet akarunk elvegezni rajta. Nyit nekunk egy egyiranyu csatornat az adathoz. Ott bedobjuk a muveletet es megcsinalja a valtoztatasokat. Mondjuk ez csak egy eleg bena elkepzeles, mert ha ehhez a kodhoz hozzaferunk azt vissza lehet fejteni.
Az a baj a világgal, hogy a hülyék mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.
Amúgy aki jártas a témában az tudja hogy van Stream Chipher [link]
Nem kell a teljes adatot egyszerre feloldani és gyors.
Aki szintén jártas a témában az tudja, hogy nem jó az ha ismétlődik valami a titkosított szövegen (végeredményen).
A titkosítás fejlődését a TLS [link] nyomon követésése segíti (hisz mindennap mindenki használja és támadják így fejlődik). Illetve az új probléma a [link] az adatok elrejtése quantum számítógépek elől.
Én azért váltottam AMD-re mert az intelben vannak elő sebezhetőségek [link] nem követtem most nyomon, de remelemt a 11 genre már megoldották, mert mikró kóddal nem tudták javítani. Az Intel valóban gyorsabban titkosít AES-t mint az AMD, de hiába, a víz ha lyukas a bögre.
Azért kíváncsi vagyok mit akarnak kihozni, de alap tétel a titkosítás téren, hogy az algoritmus ismert/publikus legyen, a bemenet és kimenet ismeretében a kulcs nem/vagy nagyon nehezen vissszafejthetőnek kell lennie. Ha a linuxal szövetkezett volna, elhinném, hogy valóban valami komoly eljárást akarnak amit bárki tesztelhet, láthat és meggyőződhet.
[ Szerkesztve ]
Cuccok: https://de.pcpartpicker.com/list/CFbYZJ
A kettőnek nem tudom mi köze van egymáshoz. A technológiát nem az AMD fejlesztette ki...
The further a society drifts from truth, the more it will hate those that speak it. (George Orwell) [Work Machines: HP EliteBook, HP ProBook & Linux Mint 20 ; Entertainment: Apple Macbook AIR M1]
Azért ez eléggé kínai szöveg volt. Most ha úgy megnézed, hogy a DARPA eddig mit adott a világnak, akkor annyira ezt nem veszem komolyan amit írtál. Még mindig előbb hiszem el, hogy valamit csinálnak jól, mint mondjuk olyan szervezetek, amik eddig csak vagy lopták a technológiát, vagy csak simán nem ismerik a történelmet.
The further a society drifts from truth, the more it will hate those that speak it. (George Orwell) [Work Machines: HP EliteBook, HP ProBook & Linux Mint 20 ; Entertainment: Apple Macbook AIR M1]
Képzeld mekkora botrány lesz belőle, ha kiderül hogy a titkosított adatot úgy is lehet manipulálni, hogy nem is oldották fel a titkosítást 🤣
Végén már digitális aláírást is kell csinálni mellé, hogy ne lehessen manipulálni bármit.
Security risc-ből feature ✨🎉
[ Szerkesztve ]
Cuccok: https://de.pcpartpicker.com/list/CFbYZJ
Ez a megvalósítástól függ. Ha az algoritmusok és az azokat gyorsító hw open source akkor tőlem a KGB is csinálhatja, ha lesz benne backdoor akkor open jellegéből adódóan ki fog derülni. Ha nincs benne akkor meg miért ne lehetne használni a készítő kilététől függetlenül.
Ezt nem teljesen értem. Ez miért jobb vagy több annál, mint ha maga a tároló (fájlrendszer - fscrypt, partíció vagy teljes eszköz - LUKS/dm-crypt) van titkosítva
Ha jól értem azért mert jelenleg a következő zajlik:
- titkosított adat beolvasása
- titkosítás feloldása
- műveletek elvégzése
- eredmény titkosítása
- titkosított eredmény mentése
A fenti lépéseknél a művelet elvégzése közben (sőt, feloldás után közvetlen, valamint titkosítás előtt a végeredmény) védtelen. Nem egy sebezhetőség arra játszik, hogy nem a tárolt adatot lopja el hanem művelet közben lopja ki a CPU-ból. Ezellen a legerősebb titkosítás se véd.
A cikkben szereplő módszer ezt akarja kiküszöbölni azzal, hogy művelet közben is titkosítva van az adat, tehát nincs a folyamatnak veszélyeztetett lépése.
Persze erre lehetne azt mondani, hogy úgy kéne megcsinálni a CPU-at meg a többi hw-t, hogy ne lehessen belőle kilopni adatot működés közben. A helyzet viszont az, hogy könnyű azt mondani. A CPU-k végtelenül összetett szerkezetek amiket emberek terveznek, lehetetlen elvárás, hogy tökéletesek és hiba nélküliek legyenek a valóságban. Így nem az a kérdés, hogy ki lehet-e lopni egy CPU-ból adatot működés közben hanem az, hogy mikor találja meg valaki a hibát amit ki lehet használni.
Viszont ha titkosítva marad az adat a műveletek közben akkor egyel kevesebb támadási felület. Így szerintem érdemes kutatni a területet.
Ja, de a cikkből úgy tűnik ez feature nem pedig hiba :/
Cuccok: https://de.pcpartpicker.com/list/CFbYZJ
Mármint inkább tered ad hardveresen a manipulációnak.
Talán az lenne a cél, hogy az ssd-rol a monitorig a felhasználó titkosítva tudjon mindent? Nem overkill? Inkább a hálózat és a wifi biztonságot kéne fejleszteni és a sandbox futtatást támogatni (minden program szeparált).
Cuccok: https://de.pcpartpicker.com/list/CFbYZJ
"Másra jó"
Megnéztem és valóban arról van szó, hogy direktben titkosított adatot lehet módosítani dekódolás nélkül ahogy lezso6 írta.
Innentől bennem is ez merült fel. Gyk. fáradtság nélkül lehet adatot manipulálni. Nyilván nem erre találták ki, hanem arra, hogy az eredeti adathoz ne juss hozzá. Pl. harmadik fél aki kezeli. Mellette viszont lehet rajta műveletet végezni. Az illetéktelen módosításra meg vmi más védelem kell mellé.
A konkrét adat felhasználásához meg egyszer úgyis dekódolni kell majd de az már lehet, hogy máshol/védett környezetben zajlik majd.
Szóval ez az egész szvsz egy specifikus célra jó.
Az elején úgy is tele lesz sok eddig fel nem fedezett hibával (a végére is marad 5 év múlva is):
Dekódolom a saját biztonsági mentett adatom, és a következő nyílik meg: [link]
Végül is senki sem tudja már meg mi volt eredetileg [kép]
MS -el fejlesztik, gondolom alapértelmezetten be lesz kapcsolva a következő Windows frissítéssel amit nem lehet kikerülni
[ Szerkesztve ]
Cuccok: https://de.pcpartpicker.com/list/CFbYZJ
Ezt én is értem, de alapvetően mégis azt kell, hogy feltételezzem, hogy érdemi számítások elvégzéséhez mindenképpen vissza kell fejteni valahol az adatokat. Egy ténylegesen titkosított adathalmazon nem lehet valós műveleteket elvégezni. Ez a lényege neki, ettől titkosítás. Ha pedig valahol a CPU-ban előkerül a titkosítatlan adat, akkor azt ugyanúgy ki lehet nyerni a különböző sebezhetőségek kihasználásával.
<-ƘƘ->
Hét azért vicces hogy a gépen belül minden milliméteren belül legyen high-end security, de a routerek és egyéb eszközök meg még frissítést sem kapnak néha .
Cuccok: https://de.pcpartpicker.com/list/CFbYZJ
Matematikailag létezik ilyen. Gondolj bele, eleve az aszimmetrikus titkosítás is hasonlóan hülyén hangzott régen, mert ott ugye két kulcs van: a publikus kulccsal titkosítasz, míg a privát kulccsal megfejtesz. Wtf, hogyan? Hát matek, ott az RSA, nap mint nap használjuk.
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
Hát lassan már inkább az elliptikus görbéket kéne nap mint nap használni mint az SSH-ban ed25519, ed448-at is várom.
Cuccok: https://de.pcpartpicker.com/list/CFbYZJ
Jah, valószínűleg csak félreértem a dolgot, illetve a célt. Egy normál titkosított adathalmazon nem lehet megmondani, hogy melyik része mi. Vagyis amivel már példálóztál, azt alapvetően nem lehetne kivitelezni. De persze ha nem az egész van letitkosítva, hanem csak a részei (mondjuk csak a számok), és pontosan tudni, hogy mi-mi, akkor úgy már lehet végezni rajta számításokat. És a végén csak az fogja tudni az értelmes végeredményt akinél van a feloldókulcs.
De ez így nem leváltja a tárolás titkosítását, hanem csak kiegészíti azt.
<-ƘƘ->
[ieeexplore.ieee.org/document/9265535]
Ebben a kidolgozásban minden hagyományos: AES and hash csak még "Domingo Ferrer (DF) encryption scheme" használnak hozzá . "The main importance of the usage of HE in this application is allowing the process over encrypted data at the cloud side such as computing encrypted students' average."
[ Szerkesztve ]
Cuccok: https://de.pcpartpicker.com/list/CFbYZJ
Igen, szóval a titkosított adatról pontosan lehet tudni, hogy milyen fajta információt tartalmaz. De ez teljesen más dolog mint a hagyományos tárolás vagy adattovábbítás titkosítás. Olyannyira, hogy kár is volt belekeverni a hírbe. Ez így egyáltalán nem reformálja meg a titkosítást, hanem csak egy teljesen újfajta felhasználási formája.
<-ƘƘ->
Ezért is akadtam, ki, hogy nekem ne manipuláljon senki semmit pl egy backup-on: [link]
[ Szerkesztve ]
Cuccok: https://de.pcpartpicker.com/list/CFbYZJ
Számomra így lenne logikus, ha: memória/cache->hardveres dekódolás->nem hozzáférhető cache->feldolgozás*->nem hozzáférhető cache->hardveres kódolás->memória/cache-be visszaírás módon történne.
*A hagyományos és a (nem hozzáférhető) cache között át kell kapcsolni a magot a feldolgozás idejére, feltéve hogy erre nagy teljesítményű magot lenne célszerű használni. De mivel a hardveres dekódolás/kódolás még relatíve lassú, valószínű nem lesz rá optimális a kihasználás, egyelőre kaphat akár dedikált, kisteljesítményű magot is, amit teljesen el lehet zárni a külső hozzáféréstől.
[ Szerkesztve ]
Itt most nem erről van szó. Hanem arról, hogy vannak titkosított adataid, de egyáltalán nincs hozzá feloldókulcsod. Amit tudni lehet az az, hogy milyen típusú adatokról van szó. Pl. valamilyen szám, de azt nem tudod, hogy pontosan mi az értéke. És ezekkel kell valamit kezdeni, különböző számításokat és műveleteket lehet végezni rajtuk, a lényeg, hogy a titkosított végeredmény az megegyezzen azzal mintha titkosítatlanul lett volna feldolgozva, és úgy lett volna újratitkosítva.
<-ƘƘ->
Es ne tudjak ennyibol visszaszerezni a kulcsot se. Ez itt az igazan nehez feladat, mert ha pl engedi a 0-val valo szorzast, akkor maris tudni fogom az eredmenyt, a ciphertextet es attol mar a kulcsra valamilyen mertekig lehet kovetkeztetni. Szerintem maga a muvelet is titkositva kell, hogy legyen.
[ Szerkesztve ]
Szerencsére alaptétel [link], ahogy az utolsó bekezdésben említettem, nem lehet a kulcsot visszafejteni úgy, hogy ismered a titkosított és titkosítatlan szöveget, ez az első amire figyelni kell. Meglévő algoritmusokat használnak. Inkább az a kérdés, mi van ha, valakit nem érdekel a kulcs vagy az eredeti rejtjelezett érték, hanem neki az a fontos hogy manipulált legyen, ahogy írtad, lenullázza vagy olyan értékre állítja amivel később visszaélhet.
Példa: seed érték titkosítva és valaki megpiszkálja 
[ Szerkesztve ]
Cuccok: https://de.pcpartpicker.com/list/CFbYZJ
Visszafejteni nem is, de az erosseget mar csokkenti igy a bruteforce tamadasok idejet is csokkenti.
Pl. a counteres stream ciphereknek ugy csinaljak ezt, hogy nem ismert a counterbol eloallitott ertek amivel xoroljak a plaintextet ezert nem lehet a kulcsra kovetkeztetni. De muveletvegzesnel ugyan abban a blokkban ez counter ertek valtozatlan, tehat ki fog esni.
[ Szerkesztve ]
Magát a műveletet nem lehet titkosítani, mert ahhoz is tudnod kellene a kulcsot.
A nullával való szorzást azt mindig engedi, és nyilván annak 0 lesz az eredménye. De az, hogy ezt tudod, még nem jelenti azt, hogy onnantól kezdve minden más értéket is vissza tudsz fejteni.
Szóval teszem azt az eredeti érték 135, ami titkosítva UROphis3j9WjIvj,4Xdc,SRdFGzQ12Zlc5YfoN4s4o2X39jA+SoteB. Ez valós, most titkosítottam és ez jött ki. Ezt a számot ha megszorzod nullával akkor kapsz egy 04Z6PW0O+IPnZvK2UeZsrXsIqu6W8WQB+UlzTH3Y7KPC9XFg6RBdvA titkosított értéket. Ezt ugyanúgy titkosítottam mint a 135-öt, és ezt dobta rá. Ha tudod, hogy ez valójában 0, akkor már tudod azt is, hogy a másik az pedig 135? Mert nem hiszem...
Na amit nehezen tudok elképzelni, hogy ezt ténylegesen össze lehet hozni csak annyi infóból, hogy tudom egy karaktersorozatról, hogy az valamilyen számértéket rejt.
Ugyanakkor, azt már el tudom képzelni, hogy több ilyen titkosított értéket össze lehet vetni, és pl. átlagolni lehet valahogyan.
<-ƘƘ->
Igen, de nem a muveletvegrehajtas helyen kell tudnod. Pl. ha a nyugdijfolyosito intezet elrendeli, hogy mindenkinek szorozzak meg 2-vel a nyugdijat, akkor eloallitjak ezt a muveletet titkositva, a szervereken meg mar csak vegre kell hajtani a lekuldott titkositott muveletet.
Ha titkositas nelkul tudsz muveletet vegezni az eleg veszelyesen hangzik. Pl. tarolsz egy uin16-ot. Ha te megszorzod 0-val tudod hogy milyen ciphertext lesz, amikor 0 az erteke. Innentol kezdve mar csak el kell kezdened mindig 1-et hozzaadni es ha tulcsordul 0-at kapsz, azt meg eszreveszed abbol, hogy ugyan azt a ciphertextet kaptad. Es mar ki is derult mi a tarolt ertek a kulcs ismerete nelkul is.
[ Szerkesztve ]
Jó, de most maradva a példámnál, mivel én is azt írtam, hogy több ilyen titkosított értéket talán össze lehet vetni matematikailag. Ha nem tudom, hogy a 04Z6PW0O+IPnZvK2UeZsrXsIqu6W8WQB+UlzTH3Y7KPC9XFg6RBdvA az valójában 0, de összeszorzom két másik titkosított értékkel, akkor elvileg ugyanezt kellene kapnom eredménynek. Innentől fogva meg már tudom is, hogy ennek az értéke 0. Mivel a nullával való szorzás eredménye az ugyanúgy 0. Azért ez is veszélyes ha ez így tényleg működik. Bár nekem inkább csodának hangzik, mintsem ténylegesen megvalósítható dolognak.
<-ƘƘ->
Viszon ha titkositott a muvelet, akkor azert nem akkora csoda 
Ugy megvalosithato biztonsagosan.
[ Szerkesztve ]
Magát a műveletet (ez esetben a szorzást) azt azért már nem lehet titkosítani, mert akkor nem tudná a processzor, hogy mit csináljon.
<-ƘƘ->
Ha a titkositas szorzasokkal es osszeadasokkal mukodik akkor azert ez megsem olyan lekepzelhetetlen
azért van xor és modulus is 😜
Cuccok: https://de.pcpartpicker.com/list/CFbYZJ
Marmint az eddigieknel, de most arrol van szo, amit fejlesztenek ebbol a celbol.
Szerintem a valóságban nem fejlesztenek ki új dolgot hanem a meglévő homomorf megvalósításokat képezik le hardveresen.
[ Szerkesztve ]
Cuccok: https://de.pcpartpicker.com/list/CFbYZJ
Egy számnak lehet rengeteg titkosított reprezentációja, ha hozzáadsz valami véletlen "zajt", amit a dekódolás majd kiszűr. Szóval, a példád esetén, nem fogod tudni, hogy mindkét művelet eredménye ugyan az.
[ Szerkesztve ]
És ezekkel hogyan lehet számolni?
Vegyük csak a legegyszerűbb titkosítást, az egyes számokhoz hozzárendelünk egy másikat:
0 -> 7
1 -> 9
2 -> 4
3 -> 6
4 -> 8
5 -> 3
6 -> 0
7 -> 5
8 -> 2
9 -> 1
így pl. a
153 * 458 = 70074
titkosítva 57758
936 * 832 = 778752
Mégis milyen matematikai képlettel lehetne leírni, hogy a titkosított 936 és 832 értékek szorzata 57758 legyen?
Ha ehhez még hozzávesszük azt is, hogy titkosítva nem is számokkal kell dolgozni hanem random karakterekkel, plusz akkor még extra zajt is hozzácsapunk, akkor végképp halvány lila gőzöm sincs, hogy ez mégis miként működhet. Nekem teljesen lehetetlennek tűnik, akkor is ha milliószor számolja át a CPU.
<-ƘƘ->
nézz utána ennek: Domingo Ferrer DF
Cuccok: https://de.pcpartpicker.com/list/CFbYZJ
Jah, szóval jól gondoltam, hogy ez így nem működik. Hanem speckó képletekkel kell dolgozni, amikbe be vannak helyettesítve az adatok. Ami azt is jelenti még mindig, hogy ez nem a meglévő titkosítási megoldásokat váltja, és nem is modernebb azoknál. Hanem csak arról van szó, hogy titkosított formában lehet számolni számokkal.
<-ƘƘ->
Hogy hogyan lehet, azon sok matematikus sokat agyalt. De az alapötlet az, hogy csak pár egyszerű alapműveletre kell kitalálni ezt, amiből fel lehet építeni a komplexebb műveleteket. Tehát mondjuk, klasszikus elég sokmindenre jó alapmüvelet a NAND (azaz logikai ÉS, aztán logikai NEM). Ha arra megoldják, akkor már automatikusan megoldották az összeadásra is, szorzásra, stb., szóval minden műveletre, amit egy CPU-k iterálás nélkül meg tud csinálni (mivel az olyan logikák mindíg kiépíthetőek tisztán NAND kapukból).
Nem a meglévő titkosítás helyett van, hanem arról szólna ez, hogy egy nem megbízható helyen tudsz számoltatni "privát" adatokkal. Nem megbízhatóság alatt itt azt értem, hogy attól félsz, hogy ellpoják az adatokat amikkel számolsz. Hogy ennek lesz-e praktikus alkalmazása, főleg szélesebb körben, azt nem én sem látom. Már ott kezdődik a gond, hogy bár bármilyen matematikai műveletet el tudsz végeszni, ami az általam említett alapműveletekből kirakható, rengeteg algorimus iterációt igényel, vagy simán csak sok feltételes elágazást, azaz control flow van bennük. Na most azokat úgy kell ábrázolni, hogy minden lehetséges utat kiterítesz egy baromi nagy kifejezésben (amiben tehát nincs flow control), az bár matematikal lehetséges, pillanatok alatt nem lesz praktikus, mert "felrobban" a kifejezésed mérete. Innentől kezdve nem tudsz bármilyen számítást elvégezni. Ja, és minden algoritmusnak a worst case időkomplexitását kapod. Vagy ha megengedsz valódi elágazásokat (valódi alatt azt értem, hogy csak az egyik ágon mész tovább a számítással), ideértve valódi iterációt is, akkor meg nagyon kéne vigyázni, hogy a programo futási idejéből, meg egyáltalán hogy melyik műveletet hányszor hajtottad végre, ne lehessen következtetéseket levonni a titkos adatodra. Szóval... nem értem, miért látnak ebben akkora fantáziát. Persze matematikai érdekességnek/bravurnak már biztosan jó, szóval ha még fizeti is valaki, hogy csinálják... ![;]](http://cdn.rios.hu/dl/s/v1.gif)
