---

Hej!

Jeg har fået en lille skoleopgave hvor jeg skal beskrive kryptografi... og
forskellige metoder:
Så nu er jeg begyndt at læse, læse og læse....

Øhhh....
jeg kan så læse på Internettet , at der både er symmetrisk og asymmetrisk
kryptering!

Der er to ing jeg har tænkt på:

1)
Såvidt jeg kan læse er Public-Key-metoder (asymmetrisk) mest sikre - da de
aldrig er blevet brudt!
Hvorfor bruger man egentlig ikke altid Public-Key (asymmetrisk kryptering),
nu det er SÅ sikkert ????

2)
Jeg vil gerne lave en beskrivelse af Tunnel-protokoller, Krypterings- og
autentificerings-metoder osv.

Relevante tunnel-protokoller at skrive om: PPTP, L2TP, IPSec
Er der andre tunnel-protokoller ?

Er der nogen som kan hjælpe mig med en liste over
Relevante krypterings-algoritmer , som I synes jeg skal skrive om:
DES, 3DES, AES osv.?

Er der nogen som kan hjælpe mig med en liste over
Relevante autentifikaiton-metoder, I synes jeg skal skrive om?

3)
Er det bestemt at AES skal være Rijndael?
Hvorfor skal der findes en afløser til 3-DES når den er så sikker?


Hilsen
Benny Sørensen

---

In article <FxS08.4$Eu2.1858@news010.worldonline.dk>, bs wrote:
>
> 1)
> Såvidt jeg kan læse er Public-Key-metoder (asymmetrisk) mest sikre - da de
> aldrig er blevet brudt!
> Hvorfor bruger man egentlig ikke altid Public-Key (asymmetrisk kryptering),
> nu det er SÅ sikkert ????

Det kræver meget regnekraft at benytte disse systemer. Derfor bruger man
ofte assymetriske metoder til at generere en såkaldt session-key, som
man derefter krypterer dokumentet (eller dele af dokumentet) med en helt
almindelig symmetrisk algoritme.

> Relevante tunnel-protokoller at skrive om: PPTP, L2TP, IPSec
> Er der andre tunnel-protokoller ?

IPsec er ikke så meget en tunnel-protokol som en transport-protokol.
Ofte bruger man L2TP som tunnel-protokol i forbindelse med IPsec.

> Er der nogen som kan hjælpe mig med en liste over
> Relevante krypterings-algoritmer , som I synes jeg skal skrive om:
> DES, 3DES, AES osv.?

Alle tre er symmetriske. Måske vil du også have nogle assymetriske såsom
RSA med her?
Alt efter hvilken form for skoleopgave du skriver kan det være relevant
at have historiske algoritmer med såsom Caesar, Enigma og
Merkle-Hellman.

> 3)
> Er det bestemt at AES skal være Rijndael?

Ja.

> Hvorfor skal der findes en afløser til 3-DES når den er så sikker?

Det er den ikke, og den vil blive endnu svagere med tiden.

--
Andreas Plesner Jacobsen | Who's scruffy-looking?
|    -- Han Solo

---

> Derfor bruger man
> ofte assymetriske metoder til at generere en såkaldt session-key, som
> man derefter krypterer dokumentet (eller dele af dokumentet) med en helt
> almindelig symmetrisk algoritme.

Jeg forstår det, hvis du mener at man bruger ass. metoder til at formidle de
symmetriske nøgler. Men hvis selve den assymmetriske metoder genererer
neøgle... ja så forstår jeg det ikke rigtigt... sorry, hvis jeg virker lidt
tung

> IPsec er ikke så meget en tunnel-protokol som en transport-protokol.
> Ofte bruger man L2TP som tunnel-protokol i forbindelse med IPsec.

Hvorfor bruger man en L2TP-tunnel i forb. med IPSec.?

Når du skriver "transport-protokol" foregår det så på lag 4?
Jeg troede IPSec lå på lag 3...? Men det er vel også lige meget...
Men det væsentlige er, at jeg ikke forstår hvorfor der skal bruges en
speciel Tunnelprotokol på de nedre lag, når nu kryptering/aut. er froegået
på nogle af de øvre lag!
Jeg mener: kan man ikke sende IPSec ud på en alm. L2-forbindelse - f.eks.
PPP eller hvad det nu hedder.... eller SKAL de sendes over en speciel
lag-2-Tunnel-forbindelse som L2TP ???

Jeg lyder sikkert som et stort spm.-tegn... og det er jeg også... Det er
ikke fordi jeg ikke gider læse... eller ikke kan søge på Google! Det gør jeg
i stor stil... men jeg er bare lidt forvirret af de forskellige protokoller!

Hilsen
Benny

Er IPSec ikke blot nogle specielle IPSec-pakker som er kapslet ind i alm.
IP-pakker ?

---

In article <7ob18.671$Eu2.48539@news010.worldonline.dk>, bs wrote:
>> Derfor bruger man
>> ofte assymetriske metoder til at generere en såkaldt session-key, som
>> man derefter krypterer dokumentet (eller dele af dokumentet) med en helt
>> almindelig symmetrisk algoritme.
>
> Jeg forstår det, hvis du mener at man bruger ass. metoder til at formidle de
> symmetriske nøgler.

Ja, det var det jeg mente, men det var dårligt formuleret.

>> IPsec er ikke så meget en tunnel-protokol som en transport-protokol.
>> Ofte bruger man L2TP som tunnel-protokol i forbindelse med IPsec.
>
> Hvorfor bruger man en L2TP-tunnel i forb. med IPSec.?

Fordi L2TP giver dig mulighed for at tildele DNS, WINS og meget andet
dynamisk.

> Når du skriver "transport-protokol" foregår det så på lag 4?

Nej, jeg talte ikke "transport" i OSI sammenhæng.

> Jeg mener: kan man ikke sende IPSec ud på en alm. L2-forbindelse - f.eks.
> PPP eller hvad det nu hedder.... eller SKAL de sendes over en speciel
> lag-2-Tunnel-forbindelse som L2TP ???

Det kan man sagtens, men så mister man ovenstående.

> Er IPSec ikke blot nogle specielle IPSec-pakker som er kapslet ind i alm.
> IP-pakker ?

Jo.

--
Andreas Plesner Jacobsen | What's love but a second-hand emotion?
|    -- Tina Turner

---

On Wed, 16 Jan 2002 09:53:03 +0100, "bs" <bs@nospam.tak> wrote:

> Når du skriver "transport-protokol" foregår det så på lag 4?

Det fremgår, at du skal bruge det til en skoleopgave. Der ses det
ofte, at ting i skoleopgaver skal sammenlignes med OSI-modellen,
men virkeligheden er, at IP-familien af protokoller ikke 'mapper'
særlig pænt til OSI.

Så beskriv i stedet i din opgave, hvordan man kan argumentere
for, at de enkelte komponenter hører til i hvilke OSI-lag, og
hvad der i de enkelte tilfælde modsiger dette.

> Jeg mener: kan man ikke sende IPSec ud på en alm. L2-forbindelse

Jo, fx. et ethernet.

> - f.eks. PPP eller hvad det nu hedder....

Som en lille ekstraopgave, så tænk lidt over, om du synes PPP er
en virkelig L2-protokol, sådan i ISO/OSIs begrebsverden.

> eller SKAL de sendes over en speciel lag-2-Tunnel-forbindelse
> som L2TP ???

Nej.

> Er IPSec ikke blot nogle specielle IPSec-pakker som er kapslet ind
> i alm. IP-pakker ?

Nej. IPSec er en sikkerhedsarkitektur.

Men IPSec opfattes ofte som 'specielle IP-pakker pakket ind i
alm. IP-pakker', selvom det i virkeligheden kun med rimelighed er
betegnelsen for ESP i tunnel mode.

-A
--
http://www.hojmark.org/

---

> Som en lille ekstraopgave, så tænk lidt over, om du synes PPP er
> en virkelig L2-protokol, sådan i ISO/OSIs begrebsverden.

Jeg har altid betragtet PPP som en protokol på lag2...
Enten sender man det ud på Ethernet eller på en ATM-forbindelse eller en
PPP-forbinbdelse: men jeg kan næsten forstå på dit spm. at jeg tager helt
fejl!
PPP ligger sikkert et lag højere!

Hilsen
Benny Sørensen

---

On Thu, 17 Jan 2002 21:11:34 +0100, "bs" <bs@bs.dk> wrote:

>> Som en lille ekstraopgave, så tænk lidt over, om du synes PPP er
>> en virkelig L2-protokol, sådan i ISO/OSIs begrebsverden.

> Jeg har altid betragtet PPP som en protokol på lag2...

Jeg opfatter PPP som en familie af protokoller, der bla omfatter

- IPCP, der bla. bruges til udveksling af IP-adresser for
de to end-points, DNS-servere og WINS-servere.
- EAP, der bruges til authentication

Det passer jo ikke ret godt med L2, vel?

Så I praksis skal man anskue det som PPP (der er data link), der
bærer andre protokoller (fx. IPCP). Men hvis PPP er L2, hvad er
så IPCP, der ligger ovenpå PPP?

Som sagt: En referencemodel er netop kun til reference. Virkelige
protokoller, og ikke mindst IP-familien der kan Alt(TM) passer
ikke ret godt til referencemodeller.

Eksempel 2: Jeg bruger min SoftPhone til at lave en telefonsam-
tale fra mit hjem til en kollega i firmaet. Det kunne blive til
noget i stil med: Voice over G.711 over RTP over UDP over IP over
ESP over UDP over IP over PPP over ATM over ADSL.

Prøv lige at få det til at passe med OSI-modellen.

OSI-modellen kan bruges til at bibringe en basal forståelse af,
hvordan (og måske hvorfor) man laver netværk lagdelt. Men ikke
ret meget andet.

-A
PS: Vi er (igen) way off-topic for d.e.s. FUT.
--
http://www.hojmark.org/

---

Hej Benny

> 1)
> Såvidt jeg kan læse er Public-Key-metoder (asymmetrisk) mest sikre - da de
> aldrig er blevet brudt!
> Hvorfor bruger man egentlig ikke altid Public-Key (asymmetrisk kryptering),
> nu det er SÅ sikkert ????

Som Andreas skriver, er det meget langsommere end symmetrisk kryptering.
Iøvrigt mener jeg at have hørt, at asymmetriske nøgler skal være længere
end symmetriske for at opnå samme sikkerhed. Der er vist også en (lille)
risiko ved public key nøglesystemer, da man kan bruge den offentlige
nøgle til at finde den private. Dette tager dog meget lang tid, men det
er en svaghed.

> Er der nogen som kan hjælpe mig med en liste over
> Relevante autentifikaiton-metoder, I synes jeg skal skrive om?

Jeg misforstår dig måske, men kerberos er ret interessant. Du kunne også
tage noget med om one-time-passwords (s/key), men det er direkte
relevant for kryptering. Visse banker benytter dog one-time-keys i deres
webbank-systemer. Min gjorde indtil fornyligt.

> 3)
> Er det bestemt at AES skal være Rijndael?

Ja. (Men det er vel snarere Rijndael, der skal være AES.)

Mvh. Michael
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)

---

> risiko ved public key nøglesystemer, da man kan bruge den offentlige
> nøgle til at finde den private.

Øh... hvordan det ?
Jeg ved ikke så meget om det... indrømmet... så jeg vil ikke spille klog!
Men: En nøgle kan vel altid findes - forudsat at man har uendelige
ressorucer af tid og processor-kraft... Men jeg er lidt nysgerrig for at
høre: Hvoirfor er det nemmere at finde nøgel med public key ?

> Jeg misforstår dig måske, men kerberos er ret interessant.

Hvad er Kerberos? Metode til aut. eller kryoptering ????
Det må jeg lige ud og søge på...

> Men det er vel snarere Rijndael, der skal være AES.

Ja sorry, jeg var vist lidt dårlig formuleret...

Hilsen Benny!

---

bs wrote:
>
> > risiko ved public key nøglesystemer, da man kan bruge den offentlige
> > nøgle til at finde den private.
>
> Øh... hvordan det ?
> Jeg ved ikke så meget om det... indrømmet... så jeg vil ikke spille klog!
> Men: En nøgle kan vel altid findes - forudsat at man har uendelige
> ressorucer af tid og processor-kraft... Men jeg er lidt nysgerrig for at
> høre: Hvoirfor er det nemmere at finde nøgel med public key ?

Hvis du kender en offentlig nøgle kan du gå i gang med at
afprøve forskellige hemmelige nøgler. Hver gang du tager
en potentiel hemmelig nøgle kan du nemt afgøre, om det er
den rigtige. Du kunne evt. have fået stillet nogle
krypterede data til rådighed, men det gør ingen forskel,
for dem kunne du også nemt selv fremstille ud fra den
offentlige nøgle.

Hvis vi ser på et symetrisk nøgle system antager vi, at
du har adgang til nogle krypterede data, men du har ingen
oplysninger om nøglen. Du kan nu gå i gang med at
afprøve forskellige nøgler, men du har ikke nogen nem
måde, at afgøre om en nøgle er rigtig. Det eneste man kan
gøre er at foretage dekrypteringen, og teste om outputet
ser sandsynligt ud. Hvis du derimod har nogle enkelte
blokke af data, hvor du kender både klartekst og
ciffertekst kan du teste en potentiel nøgle mod disse
blokke.

Forskellen er altså at med publickey har angriberen nogle
flere oplysninger at gå ud fra. Men man kan sagtens
forestille sig, at angriberen har mange flere oplysninger
at gå ud fra, og forsøge at finde kryptosystemer der
stadig vil være sikre.

Når man vurderer et kryptosystems styrke, kan man se på
en lang række forskellige angreb. Man kan stille
scenarier op, hvor nogen af dem kaldes: known plaintext,
choosen plaintext, choosen ciffertext. Den stærkeste
kryptering man kan forestille sig kaldes for "Semantic
secure against adaptive chosen ciphertext attack".

--
Kasper Dupont
For sending spam use mailto:u972183+6138@daimi.au.dk

---

bs wrote:
>
> 3)
> Er det bestemt at AES skal være Rijndael?
> Hvorfor skal der findes en afløser til 3-DES når den er så sikker?

Jeg var i torsdags til et foredrag med Vincent Rijmen, hvor han
blandt andet fortalte, at et af kravene til AES var en bedre
performance en 3-DES. Men samtidig skulle den være mindst lige
så sikker, og i øvrigt have større blokke og nøgler en 3-DES.
Formodentlig er AES sikrere end 3-DES, blokstørelsen i 3-DES er
kun på 64 bits hvilket er for lidt. Af den grund bør man nok
aldrig bruge den samme 3-DES nøgle til mere end 512KB data.

--
Kasper Dupont

---

On Tue, 15 Jan 2002 16:31:13 +0100, Kasper Dupont
<kasperd@daimi.au.dk> wrote:

> Jeg var i torsdags til et foredrag med Vincent Rijmen, hvor han
> blandt andet fortalte, at et af kravene til AES var en bedre
> performance en 3-DES.

Algoritme-mæssigt kan det selvfølgelig sagtens være sandt (det
har jeg ingen anelse om, endsige forståelse af), men i praksis
vil 3DES performe langt bedre på de fleste platforme idag, sim-
pelthen forde det er mere modent.

.... Og de produkter, hvor man har implementeret 3DES i hardware,
der vil man skulle leve med radikalt lavere performance med AES,
eller vente på at der kommer ny hardware-assist til boxen.

-A
--
http://www.hojmark.org/

---

Hej Asbjorn

> Algoritme-mæssigt kan det selvfølgelig sagtens være sandt (det
> har jeg ingen anelse om, endsige forståelse af), men i praksis
> vil 3DES performe langt bedre på de fleste platforme idag, sim-
> pelthen forde det er mere modent.

På sigt er algoritmen mest interessant, men du har ret i, at man skal
tænke en ekstra gang, inden man investerer i AES-udstyr idag.

> ... Og de produkter, hvor man har implementeret 3DES i hardware,
> der vil man skulle leve med radikalt lavere performance med AES,
> eller vente på at der kommer ny hardware-assist til boxen.

Hvor lang tid kan man egentlig forvente, at der går, før produkterne
modnes? Har du et (godt) bud på dette?

Mvh. Michael
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)

---

On Wed, 16 Jan 2002 01:18:30 +0100, Michael Knudsen
<mk267673@but.auc.dk> wrote:

>> ... Og de produkter, hvor man har implementeret 3DES i hardware,
>> der vil man skulle leve med radikalt lavere performance med AES,
>> eller vente på at der kommer ny hardware-assist til boxen.

> Hvor lang tid kan man egentlig forvente, at der går, før produkterne
> modnes? Har du et (godt) bud på dette?

Det må jo blive en afvejning. Hvis man har brug for AES (fordi
det skal være sikrere end 3DES), så kan man jo være nødt til at
gå den vej nu. Men så bliver man også en af dem, der kommer til
at finde (eller blive udsat for) alle fejlene, inkl. exploits.
Dertil kommer alle problemerne med interoperabilitet.

For de fleste almindelige dødelige er 3DES formentlig Sikkert
Nok(TM) et par år endnu. Jeg kan ikke se, hvorfor man skulle have
specielt travlt.

-A
--
http://www.hojmark.org/

---

Hej Asbjorn

> Det må jo blive en afvejning. Hvis man har brug for AES (fordi
> det skal være sikrere end 3DES), så kan man jo være nødt til at
> gå den vej nu. Men så bliver man også en af dem, der kommer til
> at finde (eller blive udsat for) alle fejlene, inkl. exploits.
> Dertil kommer alle problemerne med interoperabilitet.

Du misforstår mig vist. Jeg mente, om du havde et bud på, hvor lang tid
der ville går, før man kunne bruge produkterne uden at støde på disse
problemer.

Mvh. Michael
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)

---

On Wed, 16 Jan 2002 13:00:59 +0100, Michael Knudsen
<mk267673@but.auc.dk> wrote:

> Jeg mente, om du havde et bud på, hvor lang tid der ville går,
> før man kunne bruge produkterne uden at støde på disse problemer.

Det troede jeg egentlig også jeg svarede på: Et par år.

-A

---

Hej Asbjorn

> > Jeg mente, om du havde et bud på, hvor lang tid der ville går,
> > før man kunne bruge produkterne uden at støde på disse problemer.
>
> Det troede jeg egentlig også jeg svarede på: Et par år.

Ah, ok. Tak.

Mvh. Michael
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)

---

> Formodentlig er AES sikrere end 3-DES, blokstørelsen i 3-DES er
> kun på 64 bits hvilket er for lidt. Af den grund bør man nok
> aldrig bruge den samme 3-DES nøgle til mere end 512KB data.

Jo, men hvad skal man så gøre...??? Dele data op i mindre størrelser???
Eller skifte 3DES-nøglen hele tiden???
(Kan det ikke være lidt upraktisk, når det er assymm. krypt.)???

Iøvrigt: Hvad er svagheden ved lille nøgle og store mængde data ?


Hilsen
Benny Sørensen

---

bs wrote:
>
> > Formodentlig er AES sikrere end 3-DES, blokstørelsen i 3-DES er
> > kun på 64 bits hvilket er for lidt. Af den grund bør man nok
> > aldrig bruge den samme 3-DES nøgle til mere end 512KB data.
>
> Jo, men hvad skal man så gøre...??? Dele data op i mindre størrelser???
> Eller skifte 3DES-nøglen hele tiden???

Data bliver allerede delt op i blokke af otte bytes
som krypteres enkeltvis, typisk vil det ske i CBC
mode.

At dele data op i 512KB blokke og kryptere dem
hver for sig i CBC mode vil ikke hjælpe, blokkenes
samlede størelse må stadig ikke overstige 512KB.

Løsningen er at skifte 3DES nøgle hele tiden. Man
kan bruge en 3DES nøgle i en periode til en eller
flere krypteringer i CBC mode, men når den samlede
mængde data er nået op på 512KB bør man udskifte
sin nøgle.

> (Kan det ikke være lidt upraktisk, når det er assymm. krypt.)???

3DES er symmetrisk. Nogle anvendelser kombinerer
assymetriske og symmetriske nøgler, man bruger den
assymetriske til at kryptere den symmetriske nøgle.
I hver session starter man med at generer en
symmetrisk nøgle som overføres med assymetrisk
kryptering og signartur. Det vil ikke være noget
stort problem at udskifte den symmetriske nøgle
efter en given mængde data. Man kan generere en ny
symmetrisk nøgle og overføre den vha. de
assymetriske tekniker. Jeg vil tro, at SSL allerede
fungerer på den måde, men jeg kender ikke detaljerne
i SSL godt nok.

>
> Iøvrigt: Hvad er svagheden ved lille nøgle og store mængde data ?

Jeg snakker ikke om en lille nøgle, jeg snakker om
en lille blok. DES anvender 56 bits nøgle og 64
bits blokke, 3DES anvender 112 bits nøgle og 64 bits
blokke.

Når man krypterer store mængder data med samme nøgle
og en lille blok risikrer man at kryptere samme data
flere gange. Hvis det sker, vil en evt. angriber
kunne se det og udnytte det. Når man har overført
2^n blokke vil der være ca. 2^(2n-1) par af blokke
som potentielt kan være ens. For hvert par er denne
risiko 2^-b hvor b er blokstørelsen. Hvis riskioen
for at dette sker skal være højst 2^-(b/2) skal
antallet af blokke højest være 2^(b/4) som i 3DES
vil svare til 512KB. Med denne mængde overførte data
er risikoen stadig mindre end 1 ud af 4 mia.
Riskoen når op på 50% omkring de 32GB data.

Med 128 bits blokke som er det mindste AES bruger
vil dette ikke være noget problem selvom man bruger
samme nøgle til 64GB data.

>
> Hilsen
> Benny Sørensen

--
Kasper Dupont
For sending spam use mailto:u972183+6138@daimi.au.dk

---

"bs" skrev:
> Jeg har fået en lille skoleopgave hvor jeg skal beskrive
kryptografi... og
> forskellige metoder:
> Så nu er jeg begyndt at læse, læse og læse....
>
God fornøjelse med opgaven. Jeg kan ikke øse ud af så megen viden selv,
men jeg kan anbefale dig at læse mere om kryptering hos den amerikanske
standardiseringsorganisation NIST:
http://csrc.nist.gov/encryption/aes/

Med venlig hilsen

Thomas B. Maxe
(som i denne forbindelse repræsenterer sig selv og ikke TDC Internet)

---

On Tue, 15 Jan 2002 10:19:29 +0100, "bs" <bs@nospam.tak> wrote:

> Relevante tunnel-protokoller at skrive om: PPTP, L2TP, IPSec
> Er der andre tunnel-protokoller ?

Der er masser, men du skal nok dele tingene lidt op.

PPTP er en tunnelmetode. Den kan køres med kryptering (MPPE) og
data transporteres i GRE. PPTP er udviklet af Microsoft, og er
oprindelig tænkt som en metode for remote access kunder at
forbinde sig til en NT-server.

L2F er en tunnelmetode. Den kan køres krypteret med bla. IPSec.
L2F er udviklet af Cisco, og er oprindelig tænkt som en metode
for en service provider at tilbyde VPNs til organisationers
remote access kunder.

L2TP er en tunnelmetode. Den kan krypteres vha. bla. IPSec. Man
kan sige, at L2TP er resultatet af, at det blev oplagt for de
fleste (inkl. Microsoft og Cisco), at det ikke nyttede noget, at
netop Microsoft og Cisco havde valgt hver deres måde at lave
stort set det samme på.

GRE er en tunnelprotokol. Den kan krypteres vha. bla. IPSec.

Man hører ofte IPSec omtalt som en type VPN, men strengt taget er
IPSec en hel sikkerhedsarkitektur for IP datakommunikation, op-
rindelig faktisk udviklet mod IPv6.

For at kunne siges at understøtte IPSec, skal et system både sup-
portere nogle krypteringsalgoritmer (fx. 3DES), noget tunnelling
(ESP), en metode til udveksling af nøgler (IKE/ISAKMP/Oakley)
etc.

Find flere links til info om IPSec i FAQ'en
http://a.area51.dk/sikkerhed/ordforklaring
eller på Net-FAQ:
http://www.net-faq.dk/cgi-bin/faqmain.pl?get=ipsec
der også har andre sider om PPTP etc.

En formel beskrivelse af IPSec er RFC2401
http://sunsite.dk/RFC/rfc/rfc2401.html

-A
--
http://www.hojmark.org/