---

Hej alle.
Jeg undskylder på forhånd, mit spørgsmål er lidt indviklet, håber i bærer
over med det.
Da jeg er ved at lave et lille filkrypteringsprogram. Er jeg kommet lidt i
tvivl om hvorledes jeg laver en nøgle til den symmetriske algoritme, jeg
gør så ledes ligenu:

Bruger EllipticCurve som asymmetrisk algorimte,og AES (256bit og CBC mode)
som den symmetriske:

1. MakeKey; //create the keys-udfra et kodeord (der selvfølgelig skal
være så unikt som muligt)
Der blir lavet en public og secret key.
2. Encrypt; //Create session key
3. KeySession-denne keysession bruges som den symmetriske password, og der
laves en ny keysseiosn for hver fil, der skal krypteres.
4. ExchangedValue-her laves der en nøgle, der skal lægges ved filen, der er
krypteret, udfra denne nøgle kan sessionkeyen, genskabes hvis man kender
secretkeyen, seesionenkeyen bruges ved dekrypteringen.

Jeg ved at ECC ved 160 bit, har en sikkerhed som RSA ved 1024 bit.
Og hvis jeg skulle bruge RSA, istedet for, skal public og secret nøgler jo
gemmes på harddisken eller et andet medie og der skulle laves et tilfældigt
kodeord til den symmetriske, der så skulles krypteres.

Min konklusion er ligenu, at jeg bruger og vil blive ved med at bruge ECC,
der skal ikke gemmes noget kodeord på puteren, men hvad synes I., jeg
besvarer gerne spørgsmål.
--
Regards
Jonathan
www.cpuid.dk

---

jonathan skrev:

>Og hvis jeg skulle bruge RSA, istedet for, skal public og secret nøgler jo
>gemmes på harddisken eller et andet medie

Hvorfor er det en forskel fra ECC (som jeg ikke kender)?

>og der skulle laves et tilfældigt kodeord til den symmetriske,
>der så skulles krypteres.

Hvorfor?
Hvis den hemmelige nøgle er hemmelig, er det vel ligemeget at den
fælles komponent (er det ikke den du kalder "symmetrisk"?) er
kendt.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

"Bertel Lund Hansen" <nospam@lundhansen.dk> wrote in message
news:91m3uu8ubvbkpohg7dhf6m8esb1fnrls32@news.stofanet.dk...
> >Og hvis jeg skulle bruge RSA, istedet for, skal public og secret nøgler
jo
> >gemmes på harddisken eller et andet medie
>
> Hvorfor er det en forskel fra ECC (som jeg ikke kender)?
Fordi de to nøgler blir lavet passwordet, du kan se mere om ECC her:
http://planeta.terra.com.br/informatica/paulobarreto/
>
> >og der skulle laves et tilfældigt kodeord til den symmetriske,
> >der så skulles krypteres.
> Hvorfor?
> Hvis den hemmelige nøgle er hemmelig, er det vel ligemeget at den
> fælles komponent (er det ikke den du kalder "symmetrisk"?) er
> kendt.
Jeg formulerede mig måske lidt dumt, det skulle jo ikke være et tilfældigt
kodeord, men et valgt af brugeren selv, der ikke gemmes, man kan jo ikke
være sikker på at de to nøgler fra RSA, ikke blir fundet på ens hd eller
andet medie.
Jonathan
>
> --
> Bertel
> http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/

---

jonathan skrev:

>> >Og hvis jeg skulle bruge RSA, istedet for, skal public og secret nøgler
>> jo gemmes på harddisken eller et andet medie

>> Hvorfor er det en forskel fra ECC (som jeg ikke kender)?

>Fordi de to nøgler blir lavet passwordet

Hvorfor kan man ikke det med RSA?

>det skulle jo ikke være et tilfældigt kodeord, men et valgt
>af brugeren selv, der ikke gemmes, man kan jo ikke være
>sikker på at de to nøgler fra RSA, ikke blir fundet på ens hd eller
>andet medie.

Det er klart, men jeg forstår ikke hvorfor man ikke bare kan
kryptere kodeordene til en vilkårlig algoritme på samme måde.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

"Bertel Lund Hansen" <nospam@lundhansen.dk> wrote in message
news:nvo3uu8eaf2akh8io99uvhl8nrdikf0vc0@news.stofanet.dk...
> jonathan skrev:
>
> >> >Og hvis jeg skulle bruge RSA, istedet for, skal public og secret
nøgler
> >> jo gemmes på harddisken eller et andet medie
>
> >> Hvorfor er det en forskel fra ECC (som jeg ikke kender)?
>
> >Fordi de to nøgler blir lavet passwordet
>
> Hvorfor kan man ikke det med RSA?
Fordi de to nøgler jo blir lavet af to primtal og ikke noget kodeord
medvirkende.
> >det skulle jo ikke være et tilfældigt kodeord, men et valgt
> >af brugeren selv, der ikke gemmes, man kan jo ikke være
> >sikker på at de to nøgler fra RSA, ikke blir fundet på ens hd eller
> >andet medie.
>
> Det er klart, men jeg forstår ikke hvorfor man ikke bare kan
> kryptere kodeordene til en vilkårlig algoritme på samme måde.
Jo det kunne man vil også, men det ville jo gøre det lidt besværligt.
PS:Sorry hvis det er lidt usammenhængende, har været oppe i 36 timer..
Jonathan

---

jonathan wrote :

> "Bertel Lund Hansen" <nospam@lundhansen.dk> wrote in message
> news:nvo3uu8eaf2akh8io99uvhl8nrdikf0vc0@news.stofanet.dk...
>> jonathan skrev:
>>
>> >> >Og hvis jeg skulle bruge RSA, istedet for, skal public og secret
> nøgler
>> >> jo gemmes på harddisken eller et andet medie
>>
>> >> Hvorfor er det en forskel fra ECC (som jeg ikke kender)?
>>
>> >Fordi de to nøgler blir lavet passwordet
>>
>> Hvorfor kan man ikke det med RSA?
> Fordi de to nøgler jo blir lavet af to primtal og ikke noget kodeord
> medvirkende.

principielt er der ikke nogen forskel på at bruge RSA og ECC - begge
metoder indebærer et eller andet hemmeligt tal, der skal gemme et eller
andet sted.

>> >det skulle jo ikke være et tilfældigt kodeord, men et valgt
>> >af brugeren selv, der ikke gemmes, man kan jo ikke være
>> >sikker på at de to nøgler fra RSA, ikke blir fundet på ens hd eller
>> >andet medie.
>>
>> Det er klart, men jeg forstår ikke hvorfor man ikke bare kan
>> kryptere kodeordene til en vilkårlig algoritme på samme måde.
> Jo det kunne man vil også, men det ville jo gøre det lidt besværligt.

det kan jeg nu ikke se. I både tilfældet RSA og ECC er der et initielt
setup, hvor nøglebase etc defineres. _For_ ECC taler, at sikkerheden er
højere for samme nøglelængde som RSA. _Imod_ ECC taler, at ECC alt andet
lige er noget mere kompliceret at implementere end RSA.

> PS:Sorry hvis det er lidt usammenhængende, har været oppe i 36 timer..
> Jonathan

Husk altid ved implementation af cryptosystemer at tage et kritisk blik
på de algoritmer du vælger "tilfældige" (prim)tal med. Hvis disse
algoritmer er dårlige, så kan det være ligegyldigt hvor store dine nøgler
er.



--
Jesper Stocholm
http://stocholm.dk
Ny FAQ for dk.edb.internet.webdesign.serverside.asp
se http://asp-faq.dk

---

> >> Hvorfor kan man ikke det med RSA?
> > Fordi de to nøgler jo blir lavet af to primtal og ikke noget kodeord
> > medvirkende.
>
> principielt er der ikke nogen forskel på at bruge RSA og ECC - begge
> metoder indebærer et eller andet hemmeligt tal, der skal gemme et eller
> andet sted.
Ved rsa, skal begge da gemmes, evt den public på en af pgp servere.
> >> >det skulle jo ikke være et tilfældigt kodeord, men et valgt
> >> >af brugeren selv, der ikke gemmes, man kan jo ikke være
> >> >sikker på at de to nøgler fra RSA, ikke blir fundet på ens hd eller
> >> >andet medie.
> >>
> >> Det er klart, men jeg forstår ikke hvorfor man ikke bare kan
> >> kryptere kodeordene til en vilkårlig algoritme på samme måde.
> > Jo det kunne man vil også, men det ville jo gøre det lidt besværligt.
>
> det kan jeg nu ikke se. I både tilfældet RSA og ECC er der et initielt
> setup, hvor nøglebase etc defineres. _For_ ECC taler, at sikkerheden er
> højere for samme nøglelængde som RSA. _Imod_ ECC taler, at ECC alt andet
> lige er noget mere kompliceret at implementere end RSA.
Jeg synes da ikke ECC er sværere...men det e rmåske bare mig.
> Husk altid ved implementation af cryptosystemer at tage et kritisk blik
> på de algoritmer du vælger "tilfældige" (prim)tal med. Hvis disse
> algoritmer er dårlige, så kan det være ligegyldigt hvor store dine nøgler
> er.
Ja selvfølgelig skal man være kritisk vedrørende implementationer af
algoritmerne, er der nogen af jer, der har link til nogle tal om hvor lang
tid og hvor meget puter kraft der skal til, for at knække en 1024 bit RSA
nøgle??
Jonathan s

---

jonathan wrote:
>>Husk altid ved implementation af cryptosystemer at tage et kritisk blik
>>på de algoritmer du vælger "tilfældige" (prim)tal med. Hvis disse
>>algoritmer er dårlige, så kan det være ligegyldigt hvor store dine nøgler
>>er.
>
> Ja selvfølgelig skal man være kritisk vedrørende implementationer af
> algoritmerne, er der nogen af jer, der har link til nogle tal om hvor lang
> tid og hvor meget puter kraft der skal til, for at knække en 1024 bit RSA
> nøgle??

En lille liste:

Factoring Using the General Number Field Sieve
# of bits mips-years required to factor

512      30,000
768      2*10^8
1024      3*10^11
1280      1*10^14
1536      3*10^16
2048      3*10^20

Factoring Using the Special Number Field Sieve
512       < 200
768       100,000
1024       3*10^7
1280       3*10^9
1536       2*10^11
2048       4*10^14

--
// Mark Gjøl
Is it better to abide by the rules until they're changed or help speed
the change by breaking them?
-- http://b0rken.dk

---

> > Ja selvfølgelig skal man være kritisk vedrørende implementationer af
> > algoritmerne, er der nogen af jer, der har link til nogle tal om hvor
lang
> > tid og hvor meget puter kraft der skal til, for at knække en 1024 bit
RSA
> > nøgle??
>
> En lille liste:
>
> Factoring Using the General Number Field Sieve
> # of bits mips-years required to factor
>
> 512 30,000
> 768 2*10^8
> 1024 3*10^11
> 1280 1*10^14
> 1536 3*10^16
> 2048 3*10^20
>
> Factoring Using the Special Number Field Sieve
> 512 < 200
> 768 100,000
> 1024 3*10^7
> 1280 3*10^9
> 1536 2*10^11
> 2048 4*10^14
Mange tak, kender du nogle generelle svagheder i ECC?
jonathan

---

jonathan wrote :

>> En lille liste:
>>
>> Factoring Using the General Number Field Sieve
>> # of bits mips-years required to factor
>>
>> 512 30,000
>> 768 2*10^8
>> 1024 3*10^11
>> 1280 1*10^14
>> 1536 3*10^16
>> 2048 3*10^20
>>
>> Factoring Using the Special Number Field Sieve
>> 512 < 200
>> 768 100,000
>> 1024 3*10^7
>> 1280 3*10^9
>> 1536 2*10^11
>> 2048 4*10^14
> Mange tak, kender du nogle generelle svagheder i ECC?

DLP ?

ECC-DLP anses normalt for sværere at løse end normal DLP, da
standardmetoderne til løsning af DLP ikke lige umidelbart kan bruges på
ECC-DLP. Ellers vil jeg tro - uden at kende dine programmeringsmæssige
evener - at eventuelle problemer ikke vil opstå i forbindelse med valget
af selve algoritmen - fx ECC - men derimod i implementeringen af den.
Koder du selv det hele fra bunden af ?

Ellers vil jeg foreslå dig at anvende nogle af de foruddefinerede kurver
fra NIST og ECC-standarden. Så kommer du ikke til at vælge en
kurve/gruppe, der er sårbar overfor angreb med si etc.

--
Jesper Stocholm
http://stocholm.dk
Ny FAQ for dk.edb.internet.webdesign.serverside.asp
se http://asp-faq.dk

---

> > Mange tak, kender du nogle generelle svagheder i ECC?
>
> DLP ?
>
> ECC-DLP anses normalt for sværere at løse end normal DLP, da
> standardmetoderne til løsning af DLP ikke lige umidelbart kan bruges på
> ECC-DLP. Ellers vil jeg tro - uden at kende dine programmeringsmæssige
> evener - at eventuelle problemer ikke vil opstå i forbindelse med valget
> af selve algoritmen - fx ECC - men derimod i implementeringen af den.
> Koder du selv det hele fra bunden af ?
>
> Ellers vil jeg foreslå dig at anvende nogle af de foruddefinerede kurver
> fra NIST og ECC-standarden. Så kommer du ikke til at vælge en
> kurve/gruppe, der er sårbar overfor angreb med si etc.
Har programmeret delphi og c i 10år...,nej, jeg programmerer ikke selv
krypteringsdelene, blir købt uden i byen..men jeg vil da gennemgå koden, for
at se om jeg kan finde nogle fejl.
Jonathan