Blood_Raven zei:
Indien ge in het buitenland zit dan gelden de buitenlandse wetten. (Ik denk dat ge in Amerika wel eens gepoept kunt zijn met al die hun terrorist act regeltjes,en andere brol: In soviet America the government controls you)
In België bent ge niet verplicht uw wachtwoord te geven onder volgende voorwaarden:
- (zoals reeds aangehaald) zelf-incriminatie (dus ook mede-plichtigheid)
- bloedverband
(kan zijn dat er nog een paar zijn maar die weet ik niet)
Indien andere gevallen dan is dit obstructie van het onderzoek. (Stond dacht ik tot 3 jaar op)
Dus zoals hierboven gevraagd: je mag perfect weigeren om het encryptiewachtwoord te geven indien...(zie hierboven). Indien ze er aan geraken dan zal het wel niet mals zijn.
Overigens wanneer men uw systeem in beslag neemt dan start men dit niet meer op.
Er wordt een snapshot genomen van uw harde schijf en daarmee werkt men verder.
Indien uw harde schijf de 'grond kust' maakt ge uzelf wel enorm verdacht, en gaan ze uw schijf wel eens grondig binnestebuiten keren.
Zoals aangehaald: er zijn methoden die de politie niet kan omzeilen. PGP is er daar één van dacht ik.(Ben daar nu niet zeker van) De meeste op AES gebaseerde producten die niet vatbaar zijn voor side channel attacks zijn ook onkraakbaar.
AES:
The design and strength of all key lengths of the AES algorithm (i.e., 128, 192 and 256) are sufficient to protect classified information up to the SECRET level. TOP SECRET information will require use of either the 192 or 256 key lengths. The implementation of AES in products intended to protect national security systems and/or information must be reviewed and certified by NSA prior to their acquisition and use."
http://www.cnss.gov/Assets/pdf/cnssp_15_fs.pdf
What about wet op privacy als argument dat je die key niet wilt afstaan?
Trouwens, AES is een vrij ingewikkeld algoritme
. Maar het is ontwikkeld national security & zal wel een hoge betrouwbaarheid kennen.
En flikken zullen PGP niet kunnen kraken hoor.
ellenwiu zei:
Ik ken niet echt iets van geencrypteerde gegevens of schijven, maar heb enkele vragen na het lezen van de topic. Ik ben altijd bang dat je zelf niet meer aan jouw gegevens kan.
Als jouw gegevens geencrypteerd zijn, moet je dan enkel een paswoord ingeven om ze te bekijken? Is het dan ook niet mogelijk om alle combinaties af te gaan?
Als je nu geencrypteerde gegevens deelt in een thuisnetwerk, moet je dan ook een wachtwoord ingeven om ze te bekijken op de andere pc?
Als de schijf bijv beschadigd geraakt kan je dan nog gegevens "redden", zoals je met sommige tooltjes kan als ze niet geencrypteerd zijn?
En als je een schijf met geencrypteerde gegevens in een andere pc stopt, kun je dan ook gewoon die gegevens bekijken door een paswoord in te geven?
Alle combinaties -> hangt af van sterkte van uw encodering natuurlijk. Een RSA-key gebruikt bij PGP is al gauw 0.25-1kB groot, daarvan ga je niet zomaar even alle combinaties af. Het decodeeralgoritme is al vrij lang & je moet elk resultaat zelf gaan controleren he, gaat niet altijd automatisch. Er zijn wel algoritmen die de pc laat toestaan onderscheid te maken tussen bv. onzinnige en zinnige tekst, maar dat valt compleet weg als het geëncrypteerde bestand een afbeelding of muziekbestand ofzo is
.
Maar om je een ander vb. te geven: paswoorden worden vaak opgeslagen in gehashte vorm. Dit komt erop neer dat men het origineel paswoord niet kan extracten uit die hash (in tegenstelling tot encryptie is hashing niet omkeerbaar!). Om te kijken of men dan het juiste paswoord ingeeft hasht men gewoon dit paswoord opnieuw en vergelijkt men de hashes. Nu is het hierbij zelfs genoeg om bij een gegeven hash EEN (willekeurig) woord te vinden dat dezelfde hash geeft. 2 veelgebruikte algoritmes hier zijn md5 en sha. Dit zijn relatief snelle (zeker md5) algoritmen. Toch duurt het om pakweg alle 3-letter combinaties af te gaan met md5 al ettellijke uren. Nu moet je ook rekenen dat dit een ^n operatie is. Stel dat je zelfs nog maar de alfanumerieke tekens gebruikt, dit zijn er een 70-tal (kleine letters, hoofdletters, nummers, zaken als _). Dan zit je voor alle 3-lettercombinaties met 70^3 mogelijkheden, veel dus. In de praktijk wordt je daarom vaak verplicht een paswoord langer als 8 tekens te maken en wordt er vaak nog eens een salt aan toegevoegd (een gekend of berekenbaar stuk data dat er achter geplakt wordt). Op die manier moet je ofwel al tekenreeksen van 15 karakters lang afgaan (wat een eeuwigheid duurt) ofwel hopen dat een kortere tekst dezelfde hash oplevert. Een omzeiling is dat vele kraakorganisaties ondertussen tabellen hebben aangelegd van reeds een hoop gehashte paswoorden. Zoeken in goed gestructureerde tabellen is immers een pak sneller en zo kan men al vaak een pak woorden uitschakelen.
Nu, dit md5 voorbeeld om maar aan te tonen dat het dus zeker lang kan duren (onmogelijk lang), stel je dan eens voor dat je die hashes niet automatisch kan vergelijken na het algoritme maar zelf steeds moet gaan kijken
.
ivm delen en mounten op andere pc: Ja, je moet dan nog altijd decrypteren (wat nogal logisch is, je info wordt nergens ongeëncrypteerd opgeslagen). En ja, dat kan nog steeds, zolang jij het juiste decrypteerprogramma/algoritme gebruikt. Ik heb er al van gehoord dat men ook systeemwaarden als salts gebruikte hiervoor (bv. om passes geëncrypteerd op te slaan), maar betwijfel dat dit in de betere moderne toepassingen nog voorkomt. Let wel: als jij een goede beveiligingsworksuite hebt kan het zijn dat die gegevens "on-the-fly" gedecodeerd worden zonder dat jij het merkt (zo werkt mijn mail plugin toch eenmaal ik het pass heb ingegeven). Voor jou lijkt het misschien dat die gegevens niet meer moeten gedecrypteerd worden, maar de machine moet dit wel nog steeds doen, er is een verschil tussen wat je waarneemt en wat je moet doen.
Ivm gegevens redden is het hier wat subtieler. Je kan dit natuurlijk doen, een geëncrypteerd bestand verschilt in niets van het gewone in die zin dat het ook maar bits zijn. Echter, als jij een gewone afbeelding recovert waarin toevallig een paar bytes verandert zijn zal je dit niet altijd even erg vinden, dit is meestal een pixeltje dat wat verkeerd staat en met een filter zeer snel kan opgelost worden. Bij geëncrypteerde data kan die verkeerde byte ervoor zorgen dat een heel blok, of worst-case, alles na die byte verkeerd wordt gedecrypteerd. Dat is natuurlijk afhankelijk van het encryptiealgoritme. Dat is hetzelfde met veel geadvanceerde compressiealgoritmes ook, deze zijn veel gevoeliger aan opslag- en transmissiefouten dan gewone data.
hopelijk was het wat duidelijk?
@dJeez: blijkbaar was het openSSL dat gehackt was op die manier, niet ssh, ik was een lettertje fout
. Die ssh die ik had gevonden had idd te maken met ssh-1.
edit: wat meer enters gezet.
edit2: en ivm zelf niet meer aan je gegevens kunnen. Het enige waar dit misloopt is als je je encryptiesleutels (en bijhorend paswoord) kwijtgeraakt. Het is daarom aan te raden als je dergelijke zaken gebruikt deze apart op een diskette op te slaan. Ik zou zelfs zeggen dat het veiliger is deze op een diskette op te slaan zodat je die ergens beter kan verbergen of meenemen of in het ergste geval kan vernietigen
.
Natuurlijk zal je voor veel moderne laptops diskette hier moeten vervangen door cd-rom of usb-stick
. Een 2e usb/cd-rom/diskette gebruik je dan als backup en kan je ergens op een veiligere plaats leggen (afhankelijk van je graad van belangrijkheid/paranoia zal dit gaan van je keukenkast tot een bankkluis).
.