---

Hejsa,

Er der nogen som har erfaring med dette produkt...??

Hvem er billigst med eks. 30 licenser...??

Jimmy

---

>Hejsa
> Er der nogen som har erfaring med dette produkt...??
>
> Hvem er billigst med eks. 30 licenser...??
>
> Jimmy
>
>Er der eks. andre alternativer, hvor man også kan fjernadministrere hvis en
bruger har glemt sit password.

Jimmy

---

Hej

Der findes flere alternativer til Safeguard - prøv f.eks. www.pointsec.com.

De bliver forhandlet af et datterselskab til Protect Data. Produktet
bruges af bl.a. TDC og KPMG.

Produktet har samme features som det du efterspørger.

Du kan bl.a. selv vælge din algoritme - f.eks. 3DES eller AES.

Regards

S@ndman wrote:

>>Hejsa
>>Er der nogen som har erfaring med dette produkt...??
>>
>>Hvem er billigst med eks. 30 licenser...??
>>
>>Jimmy
>>
>>Er der eks. andre alternativer, hvor man også kan fjernadministrere hvis en
>>
> bruger har glemt sit password.
>
> Jimmy
>
>
>

---

jesper andersen wrote:

> Du kan bl.a. selv vælge din algoritme - f.eks. 3DES eller AES.


3DES til harddisk kryptering, lyder lidt sløvt.

Mener du ikke blowfish og CAST?

Jeg er vild med deres håndtering af ANSI X9.9 for både asynkron og
synkron validering.

Dog er det svært at købe en 30 bruges version, istedet kan den driftes
hos et driftcenter.

---

"Christian E. Lysel" wrote:
>
> jesper andersen wrote:
>
> > Du kan bl.a. selv vælge din algoritme - f.eks. 3DES eller AES.
>
> 3DES til harddisk kryptering, lyder lidt sløvt.

3DES er langsom. Så brug AES i stedet, den er tre-fire
gange hurtigere. (Målt på cryptoapi under Linux 2.4.17)

>
> Mener du ikke blowfish og CAST?

Hvor hurtige er de? Og hvor sikre er de?

Valget af cipher er ikke den eneste faktor, der spiller
ind på sikkerheden. Det spiller også en rolle hvilken
mode of opperation, der anvendes. CBC mode med bloknummer
som IV er det simpleste og hurtigste. Men det er ikke
specielt sikkert, da CBC mode kun er sikkert, hvis IV er
tilfældigt. Det bedste vil være at ofre lidt ekstra
diskplads på at gemme tilfældige IV på disken, men det
gør implementationen mere kompliceret, da der ikke mere
er en 1:1 korespondance mellem logiske og fysiske blokke.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:razor-report@daimi.au.dk

---

Kasper Dupont wrote:

Hejsa Kasper, jeg udtalte mig om Pointsec.

>>>Du kan bl.a. selv vælge din algoritme - f.eks. 3DES eller AES.
>>3DES til harddisk kryptering, lyder lidt sløvt.
> 3DES er langsom. Så brug AES i stedet, den er tre-fire
> gange hurtigere. (Målt på cryptoapi under Linux 2.4.17)


Pointsec kan ikke 3DES eller AES!

Se evt. www.pointsec.com


>>Mener du ikke blowfish og CAST?
> Hvor hurtige er de? Og hvor sikre er de?

Det ved jeg ikke.

---

"Christian E. Lysel" wrote:
>
> Kasper Dupont wrote:
>
> Hejsa Kasper, jeg udtalte mig om Pointsec.

OK, jeg udtaler mig om harddiskkryptering i almindelighed.
Hastighederne er målt på den eneste harddiskkryptering,
jeg selv har prøvet i praksis. Der *burde* ikke være store
forskelle i hastigheden på forskellige produkter med
samme cipher.

>
> >>>Du kan bl.a. selv vælge din algoritme - f.eks. 3DES eller AES.
> >>3DES til harddisk kryptering, lyder lidt sløvt.
> > 3DES er langsom. Så brug AES i stedet, den er tre-fire
> > gange hurtigere. (Målt på cryptoapi under Linux 2.4.17)
>
> Pointsec kan ikke 3DES eller AES!

Det fik vi ellers lige at vide.

>
> Se evt. www.pointsec.com

Hmm, der nævner de godt nok kun Blowfish og CAST. Gad vide
hvem der kender pointsecs produkter bedst: Jesper eller
Pointsec?

Jeg kan forstå, man dropper 3DES, når det drejer sig om
store datamængder. (Den er hverken hurtig eller sikker.)

Blowfish og CAST var givetvis de bedste valg, da produktet
blev designet. Men hvorfor har de endnu ikke tilføjet AES
til listen?

>
> >>Mener du ikke blowfish og CAST?
> > Hvor hurtige er de? Og hvor sikre er de?
>
> Det ved jeg ikke.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:razor-report@daimi.au.dk

---

Kasper Dupont wrote:

> Hastighederne er målt på den eneste harddiskkryptering,
> jeg selv har prøvet i praksis. Der *burde* ikke være store
> forskelle i hastigheden på forskellige produkter med
> samme cipher.


Enig.

Men hvad med forskellen mellem CAST, IDEA og AES?

>>Pointsec kan ikke 3DES eller AES!
> Det fik vi ellers lige at vide.


Det var også derfor jeg reagerede :)

> Hmm, der nævner de godt nok kun Blowfish og CAST. Gad vide
> hvem der kender pointsecs produkter bedst: Jesper eller
> Pointsec?


Endvidere nævner den version af pointsec jeg bruger også kun om Blowfish
og CAST :)


> Jeg kan forstå, man dropper 3DES, når det drejer sig om
> store datamængder. (Den er hverken hurtig eller sikker.)

> Blowfish og CAST var givetvis de bedste valg, da produktet
> blev designet. Men hvorfor har de endnu ikke tilføjet AES
> til listen?


Pointsec er et forholdsvist komplekst produkt, håndering af flere
forskellige brugere, central administration, håndtering af forskellige
typer brugervalidering.

Jeg brugte selv en del tid på at finde ud af hvordan man kan lave
asynkron og synkron ANSI x9.9 brugervalidering, uden at det går ud over
sikkerheden i selve krypteringen af harddisken.

Måske har de deres problemer med AES, eller også yder den måske ikke
"godt nok".

---

"Christian E. Lysel" wrote:
>
> Måske har de deres problemer med AES, eller også yder den måske ikke
> "godt nok".

Hvis systemet er fornuftigt designet kan cipheren uden videre
udskiftes med en ny cipher uden at nogen andre dele af koden
behøves ændringer. Og da de tilsyneladende allerede har
forskellige ciphers af forskellige størelser har jeg svært
ved at gennemskue, hvad problemet skulle være. (Jeg synes i
øvrigt ikke, det fremgik særlig klart, om de nævnte størelser
var størelsen af nøglerne eller cipherblokkene.)

Det kan da godt være, at AES er langsommere end deres andre
ciphers, men i så fald er den nok heller ikke lige så sikker.
Hvad angår sikkerheden og hastigheden er det vel helt fint at
give brugeren mulighed for selv at vælge et passende kompromis.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:razor-report@daimi.au.dk

---

Kasper Dupont wrote:

>
> Hvis systemet er fornuftigt designet kan cipheren uden videre
> udskiftes med en ny cipher uden at nogen andre dele af koden
> behøves ændringer. Og da de tilsyneladende allerede har


Enig.


> forskellige ciphers af forskellige størelser har jeg svært
> ved at gennemskue, hvad problemet skulle være. (Jeg synes i
> øvrigt ikke, det fremgik særlig klart, om de nævnte størelser
> var størelsen af nøglerne eller cipherblokkene.)


> Det kan da godt være, at AES er langsommere end deres andre
> ciphers, men i så fald er den nok heller ikke lige så sikker.
> Hvad angår sikkerheden og hastigheden er det vel helt fint at
> give brugeren mulighed for selv at vælge et passende kompromis.

Hvad er dine erfaringer med ydelsen med AES, blowfish og AES?

---

"Christian E. Lysel" wrote:
>
> Hvad er dine erfaringer med ydelsen med AES, blowfish og AES?

Jeg har kun lavet målinger af AES og 3DES, og jeg har
vist ikke gemt resultaterne. Jeg kan blot huske, at
128 bits AES var ca. 4 gange hurtigere end 3DES, og
256 bits AES var ca. 3 gange hurtigere end 3DES.

Jeg må hellere prøve at lave nogle nye timinger næste
gang jeg roder med cryptoapi, og så måle på samtlige
ciphers og gemme reusultaterne.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:razor-report@daimi.au.dk

---

Kasper Dupont wrote:

> Jeg har kun lavet målinger af AES og 3DES, og jeg har
> vist ikke gemt resultaterne. Jeg kan blot huske, at
> 128 bits AES var ca. 4 gange hurtigere end 3DES, og
> 256 bits AES var ca. 3 gange hurtigere end 3DES.


ok.


> Jeg må hellere prøve at lave nogle nye timinger næste
> gang jeg roder med cryptoapi, og så måle på samtlige
> ciphers og gemme reusultaterne.


Google gav følgende:

http://crypto.radiusnet.net/archive/libraries/cryptolib/benchmarks.html

http://www.guardcomplete.com/algo_e.html

http://lists.gnupg.org/pipermail/gnupg-devel/2000-October/005388.html

---

"Christian E. Lysel" wrote:
>
> Kasper Dupont wrote:
>
> > Jeg har kun lavet målinger af AES og 3DES, og jeg har
> > vist ikke gemt resultaterne. Jeg kan blot huske, at
> > 128 bits AES var ca. 4 gange hurtigere end 3DES, og
> > 256 bits AES var ca. 3 gange hurtigere end 3DES.
>
> ok.
>
>
> > Jeg må hellere prøve at lave nogle nye timinger næste
> > gang jeg roder med cryptoapi, og så måle på samtlige
> > ciphers og gemme reusultaterne.
>
> Google gav følgende:
>
> http://crypto.radiusnet.net/archive/libraries/cryptolib/benchmarks.html

Den side nævner følgende hastigheder:
DES 7.0 MB/s
Blowfish: 8.6 MB/s
CAST-128: 8.6 MB/s
AES: 11.2 MB/s
På en Celeron 450MHz

Øverst på siden står der, at det er en liste over ciphers.
Men et hurtigt kig ned over listen afslører, at det er en
blanding af ciphers og hashfunktioner. Det bør naturligvis
gøre læseren noget mistænkelig.

Det undrer mig egentlig lidt, at MARS er hurtigere end
Rijndael. Jeg havde fået det indtryk, at Rijndael skulle
være den hurtigste af AES finalisterne. Men det var måske
primært på små datamængder eller 8bits processorer, at
Rijndael var væsentligt hurtigere?

>
> http://www.guardcomplete.com/algo_e.html

Denne side har målinger på en pentium 200 MHz, de er
meget langsommere end førnævnte. Er der så stor forskel
på de to CPU'er? Eller er det noget andet, der er målt.

Ifølge denne side er Blowfish en del hurtigere end
Rijndael. Så det må næsten være klart, at minimum en af
de nævnte målinger ikke er foretaget på en optimal
implementation.

Desuden står der om Rijndael (AES): "Block size is 128 bit.
Max key length is 128 bit." Det lyder ikke helt korrekt.
AES definerer nøglelængder og blocklængder på 128, 192 og
256 bits. Der kan selvfølgelig godt være implementationer,
der ikke implementerer alle størelserne.

>
> http://lists.gnupg.org/pipermail/gnupg-devel/2000-October/005388.html

Interessant side. På en K6/400 er blowfish 14% hurtigere
end AES. På en Celeron/500 er AES 11% hurtigere end
blowfish. Cast5 vinder også meget på en Celeron i forhold
til en K6. Siden nævner Celerons hurtigere bitrotationer
som en mulig forklaring. Men det kan ikke forklare hvorfor
AES er så hurtig på Celeron. AES er en af de få ciphers,
der overhovedet ikke bruger bitrotationer.

Siden nævner i øvrigt også, at der ikke er optimeret så
meget på AES som de andre. Det skal blive interessant at
se, hvor hurtig den kan blive.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:razor-report@daimi.au.dk