/ Forside / Teknologi / Operativsystemer / Linux / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Linux
#NavnPoint
o.v.n. 11177
peque 7911
dk 4814
e.c 2359
Uranus 1334
emesen 1334
stone47 1307
linuxrules 1214
Octon 1100
10  BjarneD 875
Kryptere harddisk / paratition.
Fra : Esben Laursen


Dato : 12-07-04 07:50

Hej, den har sikkert været vendt før, men jeg syntes ikke lige at kunne
finde noget på groups.google.com.

Jeg har en harddisk / paratition (ikke systemet) jeg gerne vil have
krypteret. Jeg ville gerne have at det foregik på den måde at når jeg skal
have fat i de data der er krypteret, så skal jeg indtaste en kode evt. med
en private key. Jeg vil helst kunne gøre dette fra konsollen. Og jeg ville
være meget ked af at skulle kryptere alle filer enkeltvis..

Jeg kender kun "PGP disk" fra windows verdenen, som kan gøre dette, men der
findes helt sikkert nogle gode og meget sikre krypterings former til Linux.

I øjeblikket er det en 9Gig harddisk hvor alt indholdet gerne skulle
krypteres, men det er vel ikke noget problem?

Jeg kører Debian woody bare lige for at nævne det.

Håber I kan hjælpe

Hygge

Esben



 
 
Peter Jensen (12-07-2004)
Kommentar
Fra : Peter Jensen


Dato : 12-07-04 10:43

Esben Laursen wrote:

> Hej, den har sikkert været vendt før, men jeg syntes ikke lige at
> kunne finde noget på groups.google.com.
>
> Jeg har en harddisk / paratition (ikke systemet) jeg gerne vil have
> krypteret. Jeg ville gerne have at det foregik på den måde at når jeg
> skal have fat i de data der er krypteret, så skal jeg indtaste en kode
> evt. med en private key. Jeg vil helst kunne gøre dette fra konsollen.
> Og jeg ville være meget ked af at skulle kryptere alle filer
> enkeltvis..

Google efter "loopback encryption howto" eller "disk encryption howto".
Din kernel skulle gerne have et cryptographic API med diverse
krypteringsalgoritmer. Disse algoritmer kan benyttes sammen med losetup
og mount til at beskytte dine data. Det er dog en god idé at have en
backup. Ellers vil du få problemer hvis API'et ændrer sig. Der skete
en ændring et sted mellem Linux 2.4 og 2.6. Det bedste ville derfor
være at du brugte den seneste kernel.

--
PeKaJe

BOFH Excuse #215:
High nuclear activity in your area.

Soren (News) (12-07-2004)
Kommentar
Fra : Soren (News)


Dato : 12-07-04 11:34

Peter Jensen <usenet@pekajemaps.homeip.net> writes:

> Google efter "loopback encryption howto" eller "disk encryption howto".
> Din kernel skulle gerne have et cryptographic API med diverse
[snip]

Alternativt proev at lure paa bestcrypt fra www.jetico.com .


Mvh,

--
___
Soren Davidsen / o\
Deliver yesterday, code today, think tomorrow. (_____)
__ http://www.tanesha.net/ _________________________________(___)_______

Esben Laursen (12-07-2004)
Kommentar
Fra : Esben Laursen


Dato : 12-07-04 17:48

Peter Jensen wrote:
> Esben Laursen wrote:
>
>> Hej, den har sikkert været vendt før, men jeg syntes ikke lige at
>> kunne finde noget på groups.google.com.
>>
>> Jeg har en harddisk / paratition (ikke systemet) jeg gerne vil have
>> krypteret. Jeg ville gerne have at det foregik på den måde at når jeg
>> skal have fat i de data der er krypteret, så skal jeg indtaste en
>> kode evt. med en private key. Jeg vil helst kunne gøre dette fra
>> konsollen. Og jeg ville være meget ked af at skulle kryptere alle
>> filer enkeltvis..
>
> Google efter "loopback encryption howto" eller "disk encryption
> howto". Din kernel skulle gerne have et cryptographic API med diverse
> krypteringsalgoritmer. Disse algoritmer kan benyttes sammen med
> losetup og mount til at beskytte dine data. Det er dog en god idé at
> have en backup. Ellers vil du få problemer hvis API'et ændrer sig.
> Der skete en ændring et sted mellem Linux 2.4 og 2.6. Det bedste
> ville derfor være at du brugte den seneste kernel.
>

Alletiders, jeg ser frem til at læse den i dybten, jeg er nu lidt bekrymret
over at du siger ved en kerne opdatering at der så kan gå lort i API'en så
jeg ikke kan dekryptere mine data igen.... Men man burde jo bare kunne boote
op på den gamle kerne igen og hente ens data igen ikke?


Efter hvad jeg kan hurtige finde frem til understøtter den følgende
krypteringsalgoritmer:

AES aka Rijndael
Twofish
Serpent
MARS
RC6
DFC
Blowfish
IDEA
3DES
RC5

Jeg kender AES, TribleDES og en lille smule til Blowfish, jeg mener at have
læst et eller andet sted at blowfish skulle være den mest sikre, men dog
skulle dens algoritme ikke være verdens hurtigeste.. Har jeg ret i det?

Men ellers tak for hjælperen, det er altid rart med lidt doku, inden man
dykker ned i noget man faktisk ikke har den store forstand på =)

Hygge

Esben



Peter Jensen (12-07-2004)
Kommentar
Fra : Peter Jensen


Dato : 12-07-04 19:48

Esben Laursen wrote:

> Alletiders, jeg ser frem til at læse den i dybten, jeg er nu lidt
> bekrymret over at du siger ved en kerne opdatering at der så kan gå
> lort i API'en så jeg ikke kan dekryptere mine data igen.... Men man
> burde jo bare kunne boote op på den gamle kerne igen og hente ens data
> igen ikke?

Med visse forbehold ... Der er også nogle user-space værktøjer der skal
være klar over ændringen. Med Gentoo gik det vistnok galt et sted
mellem 2.4.2? og 2.6. Alt skulle være OK, hvis man bare holder sig
konsekvent til den nye serie.

> Efter hvad jeg kan hurtige finde frem til understøtter den følgende
> krypteringsalgoritmer:

[Snip - liste]

> Jeg kender AES, TribleDES og en lille smule til Blowfish, jeg mener at
> have læst et eller andet sted at blowfish skulle være den mest sikre,
> men dog skulle dens algoritme ikke være verdens hurtigeste.. Har jeg
> ret i det?

Det er noget svært at sammenligne Blowfish med AES, da Blowfish er
symmetrisk, mens AES er asymmetrisk. Den relative sikkerhed af Blowfish
sammenlignet med 3xDES afhænger nok også af den valgte nøglelængde. Jeg
ved ikke hvor du har læst at Blowfish skulle være langsom. Så vidt jeg
kan se er den betydeligt hurtigere end f.eks. 3xDES.

> Men ellers tak for hjælperen, det er altid rart med lidt doku, inden
> man dykker ned i noget man faktisk ikke har den store forstand på =)

Du kan øve dig på en almindelig fil på f.eks. 10 MB før du kaster dig ud
i at kryptere en hel partition. Hvis du er ligesom mig, så går der et
par forsøg inden teknikken er helt forstået

--
PeKaJe

If you want to know what god thinks of money, just look at the people he
gave it to. -- Dorthy Parker

Niels Callesøe (12-07-2004)
Kommentar
Fra : Niels Callesøe


Dato : 12-07-04 22:05

Peter Jensen wrote:

> Det er noget svært at sammenligne Blowfish med AES, da Blowfish er
> symmetrisk, mens AES er asymmetrisk.

Både Blowfish og AES (Rijndael) er symmetriske block-ciphers, så vidt
jeg ved. Måske tænker du på RSA public-key encryption?

--
Niels Callesøe - dk pfy
pfy[at]nntp.dk - http://www.pcpower.dk/disclaimer.php

På det digitale natbord: Applied Cryptography, Menezes et al. 1996-2001

Peter Jensen (12-07-2004)
Kommentar
Fra : Peter Jensen


Dato : 12-07-04 23:51

Niels Callesøe wrote:

>> Det er noget svært at sammenligne Blowfish med AES, da Blowfish er
>> symmetrisk, mens AES er asymmetrisk.
>
> Både Blowfish og AES (Rijndael) er symmetriske block-ciphers, så vidt
> jeg ved. Måske tænker du på RSA public-key encryption?

Doh! Det er rigtigt! Jeg kom vist til at blande TLA'er sammen

--
PeKaJe

"When the going gets tough, the tough get empirical."
      -- Jon Carroll

Kasper Dupont (16-07-2004)
Kommentar
Fra : Kasper Dupont


Dato : 16-07-04 18:56

Esben Laursen wrote:
>
> Jeg kender AES, TribleDES og en lille smule til Blowfish, jeg mener at have
> læst et eller andet sted at blowfish skulle være den mest sikre, men dog
> skulle dens algoritme ikke være verdens hurtigeste.. Har jeg ret i det?

Jeg kender kun DES, 3-DES og AES. Der er ingen tvivl
om, at den lille blokstørrelse er en svaghed for både
DES og 3-DES. AES kører med 128 bits pr. blok og er
derfor på det punkt bedrer end alle DES varianter.
AES har desuden den fordel, at der er taget meget
hensyn til performance i designet. Jeg har på et
tispunkt målt performance på cryptoloop, og 128 bits
AES havde ca. samme performance som DES. 3-DES er
naturligvis 3 gange så langsom som DES. 256 bits AES
var kun ca. 25% langsommere end 128 bits AES, og er
dermed stadig langt hurtigere end 3-DES. Det er dog
kun nøglestørrelsen, der er 256 bits. AES kører altid
med 128 bits blokke. Det oprindelige Rijndael proposal
specificerede blokstørrelser på 128, 192 og 256, men
det var kun 128 der blev gjort til standard.

Med den måde en cipher bruges på i cryptoloop er der
ingen pointe i at bruge små cipher blok størrelser,
så det undrer mig lidt at man har valgt kun at
implementere 128 bits blokke og ikke Rijndael med 256
bits blokke.

Bemærk at der er nogle små svagheder i den måde CBC
mode bruges på i cryptoloop. Desværre er det noget
der gør sig gældnede for stort set alle diskkrypterings
implementationer. Mig bekendt lider pgpdisk også af
denne svaghed.

Det eneste system jeg har kendskab til, der har forsøgt
at gøre noget ved problemet er Poul-Henning Kamps
implementation til FreeBSD:
http://bsd.slashdot.org/bsd/03/09/27/2225214.shtml

--
Kasper Dupont -- der bruger for meget tid paa usenet.
I'd rather be a hammer than a nail.

Niels Elgaard Larsen (14-07-2004)
Kommentar
Fra : Niels Elgaard Larsen


Dato : 14-07-04 03:08

Peter Jensen skrev:


> Google efter "loopback encryption howto" eller "disk encryption howto".

dmcrypt er nyere og nemmere.
http://www.saout.de/misc/dm-crypt/
Det kom vist ind 2.6.4

Det er snydenemt:

1. cryptsetup create krypt /dev/hdxx
2. Indtast nøglen
3. mount /dev/mapper/krypt /krypteretpartition.

Det er det hele.

dmcrypt virker korrekt med journaliserende filsystemer og kan også bruges på
partitioner, der er lavet med loop-aes (med de rigtige options).

--
Niels Elgaard Larsen
http://www.agol.dk/elgaard

Esben Laursen (14-07-2004)
Kommentar
Fra : Esben Laursen


Dato : 14-07-04 07:19

Niels Elgaard Larsen wrote:
> Peter Jensen skrev:
>
>
>> Google efter "loopback encryption howto" eller "disk encryption
>> howto".
>
> dmcrypt er nyere og nemmere.
> http://www.saout.de/misc/dm-crypt/
> Det kom vist ind 2.6.4
>
> Det er snydenemt:
>
> 1. cryptsetup create krypt /dev/hdxx
> 2. Indtast nøglen
> 3. mount /dev/mapper/krypt /krypteretpartition.
>
> Det er det hele.

Det er jo som sendt fra himmelen.

Tak.. Den vil jeg kikke nærmere på.

Hygge

Esben



Niels Elgaard Larsen (15-07-2004)
Kommentar
Fra : Niels Elgaard Larsen


Dato : 15-07-04 04:05

Esben Laursen skrev:


> Det er jo som sendt fra himmelen.
>
> Tak.. Den vil jeg kikke nærmere på.

Jeg skrevet også skrevet lidt om hvordan man kan lave en krypteret backup på
DVD.

http://www.agol.dk/elgaard/cryptbackup.html


--
Niels Elgaard Larsen
http://www.agol.dk/elgaard

Peter Makholm (16-07-2004)
Kommentar
Fra : Peter Makholm


Dato : 16-07-04 19:09

Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> writes:

> Bemærk at der er nogle små svagheder i den måde CBC
> mode bruges på i cryptoloop.

Hvad tænker du på?

--
Peter Makholm | Perhaps that late-night surfing is not such a
peter@makholm.net | waste of time after all: it is just the web
http://hacking.dk | dreaming
| -- Tim Berners-Lee

Kasper Dupont (16-07-2004)
Kommentar
Fra : Kasper Dupont


Dato : 16-07-04 21:26

Peter Makholm wrote:
>
> Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> writes:
>
> > Bemærk at der er nogle små svagheder i den måde CBC
> > mode bruges på i cryptoloop.
>
> Hvad tænker du på?

Ved korrekt brug af CBC mode er IV tilfældigt. Men
da et tilfældigt IV kræver ekstra diskplads bruger
de fleste implementationer inklusiv cryptoloop et
deterministisk IV. Det er ikke kun et spørgsmål om
de 3% af diskpladsen man ville bruge på IV, men
også at det kræver et mere compliceret layout af
data på disken.

Implementation i FreeBSD bruger faktisk også et
deterministisk IV, men da der bruges en ny tilfældig
nøgle hver gang en sektor skrives, må den formodes
at være mere sikker. Det ville selvfølgelig have
været bedre hvis man havde taget skridtet fuldt ud
og brugte både tilfældigt IV og nøgle. Det kan ikke
kræve ret meget ekstra arbejde at implementere det,
da det meste allerede må være gjort for at kunne
bruge tilfældige nøgler.

Så FreeBSD implementationen er ikke perfekt. Men
det er alligevel mit indtryk, at den er det bedste
du kan finde. Afhængigt af dit angrebsscenarie er
der endnu flere problemer at tænke på, som end ikke
FreeBSD implementationen tager højde for. For
eksempel kan man have brug for en træstruktur til
at sikre global integritet og at ændring af pasword
kan gøres sikkert og effektivt. Mit bud på hvordan
det bør gøres involverer en cipher, f.eks. AES, en
hash funktion, f.eks. MD5, og en assymetrisk
kryptering som f.eks. RSA.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
I'd rather be a hammer than a nail.

Søg
Reklame
Statistik
Spørgsmål : 177559
Tips : 31968
Nyheder : 719565
Indlæg : 6408936
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste