AnandTech - Na Anandtechu so med testiranjem predogledne in nato tudi končne izdaje Android 5.0 opazili nekoliko čudne rezultate, ko so testirali zmogljivost pomnilniškega čipa v Nexus 5. Posledično so se odločili najti delujoč testni program, s katerim so nato testirali tudi Nexus 6. Pri slednjem se jim je zdelo, da občasno deluje nekoliko počasi, a so to pripisali morda nekoliko prešibkemu grafičnemu čipu in kar 2560 x 1440 oz. dobrim 2,2 milijona točkam, ki jih mora grafični čip izrisovati na zaslon. A mnogi bralci so komentirali, da bi bila za počasnost lahko kriva enkripcija uporabniških podatkov Nexus 6 je namreč skupaj z Nexus 9 prvi, na katerem že tovarniško teče Android 5.0 Lollipop. S slednjim je Google naredil precejšnje premike v varnosti sistema, saj imajo med drugim vse naprave, ki so že tovarniško opremljene z Android 5.0, kriptirane uporabnikove podatke.
V primeru osebnih računalnikov to niti ni težava, saj imajo skorajda vsi (vsaj nekoliko zmogljivejši) pogoni SSD tudi enoto, ki skrbi za kriptiranje, a temu ni tako na mobilnih telefonih. Posledično za kriptiranje skrbi centralni procesor, ki, svoji zmogljivosti navkljub, ni optimiziran za to. V igro pridejo še pomnilniška vodila z ne pretirano široko prepustnostjo in rezultat so relativno nizke hitrosti prenosov. V sklopu testa so pri Anandtechu uspeli od Motorole dobiti posebno izdajo Androida, ki ima enkripcijo izključeno, rezultat pa so dvakrat višje hitrosti naključnega zapisovanja, medtem ko je naključno branje skoraj trikrat hitrejše, zaporedno branje pa kar petkrat hitrejše kot na Nexus 6, ki ima kriptirane uporabnikove podatke.
Sodeč po komentarjih na anandtechu Nexus 6 ima hw čip za kodiranje ("Qualcomm hardware cryptographic engine" (qce & qce40 & qce50)), vendar se je google odločil, da ne bo uporabil qualcommove rešitve ter so razvili svojo, katero sedaj fura CPU.
GTX970> Linux je spodaj, vedno lahko izklopiš, če ti ni všeč.
Zanimivo je, da so s tega vidika starejši Nexusi bolj prijazni uporabniku. Ker to, da je "Linux spodaj" ne pomeni, da ni zajebancije (če že nasprotno) za to narediti... In ovo na novo z vsako posodobitvijo.
Google se je odločil, da nebo uporabil Qulacommove zaprtokodne rešitve, politika.... Ni mi pa jasno na podlagi česa se odločajo katere zaprtokodne gonilnike bodo vključili v Nexus ROM.
V primeru osebnih računalnikov to niti ni težava, saj imajo skorajda vsi (vsaj nekoliko zmogljivejši) pogoni SSD tudi enoto, ki skrbi za kriptiranje, a temu ni tako na mobilnih telefonih.
Pa ni samo to, novejše x86 arhitekture imajo tudi strojno podprto AES šifriranje na nivoju procesorja (AES-NI ukazi)
strojni AES na procesorju še vedno ni ista reč kot vgrajen crypto engine v sam emmc kontroler recimo.
Če ne obdeluješ veliko količino podatkov je praktično čisto vseen kje se podatki šifrirajo (CPU/kontroler). Pri veliki količini podatkov pa ti takšno šifriranje na CPUju pokuri kar nekaj procesorskega časa. Je pa res da lahko procesorsko šifriranje porabiš tudi za šifriranje npr. internetnega prometa.
Procesorsko šifriranje bo kurlo več baterije in bo manj učinkovito/počasnejše.
Kaj takega v splošnem niti približno ne moreš reči, niti ni razloga za tako razmišljanje - če pogledaš N9, nima zaradi enkripcije upočasnitev pa uporablja "procesorsko" šifriranje. Zakaj? Domača naloga!
Seveda. Ampak če stvar koristi encryption engine (oz. extra inštrukcije ala AES-NI) v procesorju bo še vedno več "overheada" (hence večja poraba baterije) kot pa če bi stvar bila vgrajena direkt v eMMC. Če stvar dela na polno, še ne pomeni, da dela tudi najbolj učinkovito.
Vsekakor je tole korak v pravo smer. Posledica bo ta, da bo šifrirna tehnologija postala še bolj uporabna (v smislu optimizacije). Če pa govorimo o strojni podpori šifriranju, pa upam, da bomo tudi tukaj doživeli čim več odprtih implementacij.
In ja, deljenje podatkov z Googlom se da tudi izključiti.
Seveda. Ampak če stvar koristi encryption engine (oz. extra inštrukcije ala AES-NI) v procesorju bo še vedno več "overheada" (hence večja poraba baterije) kot pa če bi stvar bila vgrajena direkt v eMMC. Če stvar dela na polno, še ne pomeni, da dela tudi najbolj učinkovito.
Ne, prav nobenega razloga ni zakaj bi bila implementacija na CPUju kakorkoli manj učinkovita kot pa implementacija na eMMC. Razlika je v končni fazi le lokacija vezja. V bistvu je CPU implementacija lahko učinkovitejša, saj jo potem lahko uporabljaš tudi za ostale namene kot je TLS in podobno.
Vsekakor je tole korak v pravo smer. Posledica bo ta, da bo šifrirna tehnologija postala še bolj uporabna (v smislu optimizacije). Če pa govorimo o strojni podpori šifriranju, pa upam, da bomo tudi tukaj doživeli čim več odprtih implementacij.
In ja, deljenje podatkov z Googlom se da tudi izključiti.
Mislim da nekega strahu tu ni - AES implementacija je prišla v ARMv8 (ki ga uporablja Nexus 9) in bo del vseh novih CPUjev s to arhitekturo. Posledično N9 nima take upočasnitve zaradi ekripcije.
Ne, prav nobenega razloga ni zakaj bi bila implementacija na CPUju kakorkoli manj učinkovita kot pa implementacija na eMMC. Razlika je v končni fazi le lokacija vezja.
Ni res. Procesorska različica ima samo inštrukcijo, ki pospeši AES enkripcijo za faktor 10 (ali kolker pač je), še vedno pa more procesor delat. emmc implementacija ima pa cel crypto engine, ki dela samo to (če jasno sploh obstaja kaka emmc rešitev s tem). Zakaj pa misliš, da imajo ssdji vgrajen crpyto engine, če je ta procesorski tako dober ?
No, dajmo realno pogledat. Jaz programsko šifriranje na računalnikih uporabljam že več let. Sicer ko poženeš test, se hitrost lahko upočasni tudi do 40%, vendar v realnosti, pri običajni uporabi kakšne večje razlike ni opazit.
Ne gre se zato, kolk je v realnosti stvar počasnejša. Gre se za to, kolk hita majo različne implementacije na baterijo. To je bistvenega pomena pri _mobilni_ napravi.
Seveda. Ampak če stvar koristi encryption engine (oz. extra inštrukcije ala AES-NI) v procesorju bo še vedno več "overheada" (hence večja poraba baterije) kot pa če bi stvar bila vgrajena direkt v eMMC. Če stvar dela na polno, še ne pomeni, da dela tudi najbolj učinkovito.
Za temi inštrukcijami je del silicija ki skrbi samo za AES šifriranje (podobno kot FPU enota). Pri x86 arhitekturi so te inštrukcije pod oznako AES-NI pri ARMu pa so vključene v ARMv8-A set inštrukcij (na arhitekturah ARM Cortex A53 in A57 - 64 bitni ARM procesorji).
ARM se od Intel-a razlikuje v tem, da prodajajo le jedra (core) in instruction set. Tako podjetja kupijo jedra in okoli tega naredijo svojo periferijo in zapakirajo v čip ali pa naredijo svoj procesor, ki je kompatibilen z ARMom. Nexus6 uporablja procesor Krait 450 SoC (to je Qualcomm procesor podoben ARM Cortex A15 in uporablja ARMv7 instrukcije), kar pomeni, da samo jedro nima strojnega šifriranja. Pri čipih, ki imajo 32-bitna ARM jedra nekateri proizvajalci procesorjev dodajajo svojo periferijo, ki skrbi za šifriranje (vendar tega Qualcomm Krait nima).
Na ARMu lahko imaš šifriranje na nivoju cora (posebni ukazi), kot periferijo (dostop preko registrov, kot do ostale periferije) ali pa softwearsko. Če imaš šifriranje na nivoju cora jedro med šifriranjem šifrira (ne moreš za kaj drugega uporabit), ampak imaš več jeder - tako lahko na večih jedrih hkrati šifriraš in pohitriš zadevo (ali pa delajo kaj drugega). Če imaš posebno periferno enoto si po navadi omejen le na eno.
Torej ne vem od kje ti informacije, da je HW AES na nekem eMMC kontrolerju hitrejši oz. bolj varčen od ARMove ali Intel-ove implementacije ali implementacije tretjega podjetja?
Torej ne vem od kje ti informacije, da je HW AES na nekem eMMC kontrolerju hitrejši oz. bolj varčen od ARMove ali Intel-ove implementacije ali implementacije tretjega podjetja?
Kaj misliš, da je bolj varčno ? nekaj kar stoji med FTLjem v samem emmc kontrolerju, al en ukaz procesorja, ki sicer lahko dela enkripcijo mnogo hitreje kot sam procesor, ampak še vedno more delat enkripcijo na višjem nivoju... Ugibaj, kaj porabi (ne da je hitrejše) manj.
Torej ne vem od kje ti informacije, da je HW AES na nekem eMMC kontrolerju hitrejši oz. bolj varčen od ARMove ali Intel-ove implementacije ali implementacije tretjega podjetja?
Kaj misliš, da je bolj varčno ? nekaj kar stoji med FTLjem v samem emmc kontrolerju, al en ukaz procesorja, ki sicer lahko dela enkripcijo mnogo hitreje kot sam procesor, ampak še vedno more delat enkripcijo na višjem nivoju... Ugibaj, kaj porabi (ne da je hitrejše) manj.
Kar koli rečem ko ugibam. Poraba je odvisna od gretja - gretje od frekvence. Frekvenca od OSja. V glavnem težko je reči kaj manj porabi in na kakšen način bi to meril. Tudi, če se na koncu izkaže, da je implementacija v nekem kontrolerju bolj varčna kot tista v procesorju, je na koncu to slaba tolažba, če mora potem procesor softwersko šifrirat internetno komunikacijo. Če pa imaš šifriranje na nivoju procesorja (prek periferije ali direktno v jedru) je pa spet vprašanje, zakaj bi imel še eno šifrirno enoto v kontrolerju - poraba prostora...
interna komunikacija med SoCom in eMMCjem je čisto druga reč kot moja linija do ISPja pa do same strani.
Itk, če je potreba po res "hudi" enkripciji, neboš uporabo ne aes inštrukcij niti emmc varjante ampak pure software :)
Odvisno. Če imaš neke podatke, ki jih želiš šifrirati z AES jih lahko vržeš v HW ali SW implementiran engine in ven dobiš enake podatke (pri enakem geslu, seed, itd). Če podatki niso enaki jih pač z istim geslom ne boš mogel odklenit. Če bi bila varnostna napaka na samem AESu je čisto vseen s čim šifriraš.
Ko sem pisal driver za AES periferijo za freescale procesor osnovan na ARMu. Sem na računalniku z openSSL zašifriral znane podatke z znanim geslom, nato sem v driverju spreminjal podatke crypto engina tako dolgo, da nisem ven dobil enakih podatkov :).
Apeliram na bolj tinhat varjanto, da tisti HW engine počne še kej druga, kot samo enkripcijo :)
Periferija v večini primerov uporablja DMA in če ti omrežna kartica krade podatke direkt iz RAMa, je čisto vseeno s čim šifriraš :). Še večji problem pa je, da procesor tega ne ve :).
Praktično katerakoli sodobna HE implementacija AES enkripcije porabi zanemarljivo malo energije/procesorskega časa in čeprav neka rešitev porabi za faktor dve več je to čisto beezpredmetno.
Android 5.0 bi enostavno moral po defultu izklopit enkripcijo, kjer ni hardware podpore.
Še en pomislek za avtorja! Kriptiranje....morda je to polaganje koga v kripto!!!!!!!!!!1 Šifriranje pa je slovenski prevod! Anglizmov je že dovolj!
Ker je beseda "šifra" tako zelo slovenska. Šifra, cifra, ziffer. To ni Anglizem. Če beseda pri nas ne obstaja še ne pomeni da si mormo svojo izmisliti in iti z glavo skozi zid. Lažje jo je prevzeti.
Moram pisati "zgoščevalna funkcija" namesto "hash funkcija", kot da imamo funkcijo ki povečuje gostoto. Samo zato ker si je en slavist izmislil da je za Slovence najbolje, če jih nihče ne razume.
Če na Nexus 5 flashaš Lolipop factory image, tako da nič ne ostane na telefonu, a je enkripcija vključena?
Islam is not about "I'm right, you're wrong," but "I'm right, you're dead!"
-Wole Soyinka, Literature Nobelist
|-|-|-|-|Proton decay is a tax on existence.|-|-|-|-|
Tnx, moja se je OTA update-ala, kjer se enkripcija ne vključi niti vpraša ne. Pa me je zanimalo, če je z flashanjem image-a kaj drugače.
Islam is not about "I'm right, you're wrong," but "I'm right, you're dead!"
-Wole Soyinka, Literature Nobelist
|-|-|-|-|Proton decay is a tax on existence.|-|-|-|-|
