/ Forside / Teknologi / Internet / Sikkerhed / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Sikkerhed
#NavnPoint
stl_s 37026
arlet 26827
miritdk 20260
o.v.n. 12167
als 8951
refi 8694
tedd 8272
BjarneD 7338
Klaudi 7257
10  molokyle 6481
Dokumentsikring test
Fra : Gigasoft Danmark


Dato : 08-06-01 11:32

Hej til alle i der ville teste mit dokumentsikrings system.
Jeg har nu som i bad om lagt tre test dokumenter til dovnload på denne
adresse
http://www.gigasoft.dk/dks/
Klik på download test dokumenter her

Eller klik her for direkte downloadning
http://www.gigasoft.dk/dks/testdoc/testdoc.zip

I alle tre dokumenter er samme tekst
Dokumenterne er tekstfiler med ext =.txt
de er pakket i winzip
Håber i vil give mig respons på jeres test.

--
Med venlig hilsen
Gigasoft Danmark
Bjarne Østergård
www.gigasoft.dk E-mail: boe@gigasoft.dk
Tlf. 86 49 64 04


<Tekst begynd>
abcdefghijklmnopqrstuvwxyz
Hej dette er testfil 1 af 3

Testfil1= ukrypteret
Testfil2=Krypteret med nøgle hhqkkxfw
Testfil3 = krypteret således at den kun kan dekrypteres på en bestemt
maskine.


Alle tre tekstfiler indeholder samme tekst.

Disse tre tekstfiler er lavet på anbefaling og opfordring fra deltager i
diskusionsgruppen
dk.edb.sikkerhed

Håber at i der vil teste mit system vil give mig en tilbagemelding om
ressultatet.

Med venlig hilsen
Gigasoft Danmark
boe2gigasoft.dk
www.gigasoft.dk
Tlf. 86496404
<Tekst slut>




 
 
Jonathan Stein (09-06-2001)
Kommentar
Fra : Jonathan Stein


Dato : 09-06-01 20:52

Gigasoft Danmark wrote:

> Jeg har nu som i bad om lagt tre test dokumenter til dovnload på denne
> adresse http://www.gigasoft.dk/dks/ ...

Nu hvor du har offentliggjort alle algoritmerne, er der jo ikke så meget
at teste - bortset fra om der skulle være nogle huller i implementationen.
40-bit RC4 kryptering kan brydes på overskuelig tid - Jeg ved ikke hvor
kraftig kryptering, du bruger.
Jeg kan ikke lide, at begge de kodede dokumenter starter med samme bogstav
som klarteksten. Det giver mig en mistanke om, at din hashing rammer en svag
nøgle (eller indekserer du forkert, så krypteringen først starter ved andet
tegn?).

Hvad jeg ser som et større problem er, at mange af de nye funktioner, du
lægger vægt på, kræver en hemmelig krypteringsalgoritme.
Har du evner til at skrive en sikker algoritme, der ikke kan findes ved
lave reverse-engineering på programmet? Hvis du vælger en eksisterende
algoritme, er det formentlig kun et spørgsmål om tid før nogen gætter
hvilken algoritme, der anvendes.

M.v.h.

Jonathan

--
jsp-hotel.dk tilbyder profesionelle webhoteller med bl.a. Resin JSP,
PHP, MySQL, SSH/Telnet adgang, rå log-filer, grafisk statistik og
99% oppetidsgaranti.
http://www.jsp-hotel.dk/




Gigasoft Danmark (12-06-2001)
Kommentar
Fra : Gigasoft Danmark


Dato : 12-06-01 01:34


"Jonathan Stein" <jstein@image.dk> wrote in message
news:3B227E58.52FF9955@image.dk...
> Gigasoft Danmark wrote:
>
> > Jeg har nu som i bad om lagt tre test dokumenter til dovnload på denne
> > adresse http://www.gigasoft.dk/dks/ ...
>
> Nu hvor du har offentliggjort alle algoritmerne, er der jo ikke så meget
> at teste - bortset fra om der skulle være nogle huller i implementationen.
Ja men det håber jeg da ikke der er, men en helt grundig og gennemgribende
test er ikke endnu foretaget.

> 40-bit RC4 kryptering kan brydes på overskuelig tid - Jeg ved ikke hvor
> kraftig kryptering, du bruger.
Fra 64 og op. Dog med en top spærring på 256 da koden også kan anvendes og
indgå som marcro i word 97 - 2000


Men det var et godt spørgsmål, for jeg ved det knapt endnu da jeg også
forsøger at lave en nøgle som skal kunne indgå som en del af algoritmen,
altså således at krypteringsalgoritmen ikke er ens fra gang til gang.
(Dog jeg er så småt ved at opgive denne ide, den er hulens svær at mixe)

> Jeg kan ikke lide, at begge de kodede dokumenter starter med samme
bogstav
> som klarteksten. Det giver mig en mistanke om, at din hashing rammer en
svag
> nøgle (eller indekserer du forkert, så krypteringen først starter ved
andet
> tegn?).
Jeg ved ikke om jeg egentligt burde skrive dette. Men...
Koden er oprindelig udviklet i Kina (Ja grin bare men det er sandt)
Deres alfabet er så væsentlig anderleds end vores at det kan give nogle
sådanne ressultater.
Derefter er den blevet vestliggjort af et hold Amerikanere som mente at det
Kinesiske sprog for en vesterlænding næsten i sig selv er en fantastik
kryptering.
Herefter blev den lagt ud på "Planet sources code" hvor programmører fra
hele verden forbedrede på koden.

Nu er den altså endt i Virring på Djursland, og dermed på en Dansk Ng.
Og det er den skrappeste behandling den kode nogen sted i verden har været
ude for.
De virkelige eksperter er her. Det er helt sikker.
Kinesere, Amerikanere, Australiere, Russere og andet godtfolk kan godt pakke
sammen.

( "Ih hvor vi gungre" Sagde musen til elefanten, da de gik over broen) )

> Hvad jeg ser som et større problem er, at mange af de nye funktioner, du
> lægger vægt på, kræver en hemmelig krypteringsalgoritme.
Ja , men jeg kan ikke se hvorfor det skulle være så stort et problem.

Det største problem er da at hvis jeg ikke udlevere koden siger nogle at så
stoler de ikke på systemet, og når jeg så udleverer den siger andre at nu
stoler de ikke på sikkerheden for nu kender alle koden.

Hvordan skal jeg gøre alle tilfredsse?

Min konklusion er at det kan jeg ikke derfor er jeg nødt til at træffe et
valg. Og det bliver altså at koden ikke er tilgængeligt. og at der så vidt
muligt skal være mange forskellige algoritmer som besluttes ud fra nøglens
sammensætning.
Nu kan ingen udlever krypteringsalgoritmen, for ingen ville kende den.

Endda måske en kombination så et og samme dokument kan krypteres med mange
forskellige algoritmer afhængig af nøglen.

Hele sikkerheden hænger derefter, så vidt jeg kan se, på nøgleudvekslingen.

Selvfølgeligt forudsat at krypteringsalgoritmerne er sikre. Ja.
Men de findes jo i hobetal så vidt jeg her kan forstå, alle er de jo helt
fantastisk meget bedre end lige nettop den jeg har valgt at offentliggøre,
det har i da fortalt mig igen og igen.
Så her burde der da ingen problemb være.

> Har du evner til at skrive en sikker algoritme, der ikke kan findes ved
> lave reverse-engineering på programmet?
Ikke hvis jeg skal stole på denne gruppes bedømmelse af mine evner. Men jeg
kender folk der kan.

>Hvis du vælger en eksisterende
> algoritme, er det formentlig kun et spørgsmål om tid før nogen gætter
> hvilken algoritme, der anvendes.

Ja men min ide er også at den skulle variere afhængig af nøglen.

Her har jeg faktisk et spørgsmål.

Hvis man f.eks gentager den samme kryptering flere gange og F.eks blot
forskyder den nogle tegn, hvordan beregner man så om det giver større
sikkerhed og hvor meget mere.
Altså hvis man bruger den samme algoritme begge eller flere gange men
forskudt eller med flere forskellige nøgler.
Hermed mener jeg hvor meget forlænger man tiden det tager at dekryptere.

Jeg har selv forsøgt med nogle beregninger, men får nogle tal som jeg
overhovedet ikke ved om holder vand, og som ikke giver nogen fornuftig
mening.

Er der f.eks nogen der på en skala fra 1 til 10 kan sige mig hvor sikker min
algoritme er som jeg offentliggjorde her tidligere, og komme med et bud på
hvor lang tid en uautiseret dekryptering ville kunne tage.

Mange af de tal som de såkaldte eksperter kommer med passer nemlig ikke.

Jeg har selv deltaget i en test af en ubrydelig hardwarelås, som det skulle
tage masser af år at omgås. Tal som tusinde og millioner blev nævnt.
Mig og en makker fixede det på en nat.
Det var hardwarelåsen til Autocad 6.2 Og det var ikke engang særlig svært.
(Og ja jeg har betalt licens, det var min egen hardwarelås)

Så findes der overhovedet en stabil og sikker metode hvormed man med stor
sansynlighed kan forudsige en algoritmes sikkerhed?
På forhånd tak.



--
Med venlig hilsen
Gigasoft Danmark
Bjarne Østergård
www.gigasoft.dk E-mail: boe@gigasoft.dk
Tlf. 86 49 64 04












Jakob Færch (12-06-2001)
Kommentar
Fra : Jakob Færch


Dato : 12-06-01 08:00

In article <9g3ogr$2ohn$1@news.cybercity.dk>,
"Gigasoft Danmark" <boe@gigasoft.dk> wrote:

> >Hvis du vælger en eksisterende
> > algoritme, er det formentlig kun et spørgsmål om tid før nogen gætter
> > hvilken algoritme, der anvendes.
>
> Ja men min ide er også at den skulle variere afhængig af nøglen.

Hvis det, dit program foretager sig er
- Kigger på nøglen
- Vælger en krypteringsalgoritme
- Krypterer med den valgte algoritme

Så har du vel stadig kun én samlet algoritme - og har dermed ikke ændret
noget, udover at gøre din samlede algoritme lidt mere kompleks.

/Jakob

--
disclaimer: jeg havde egentlig ikke tænkt mig at blande mig i denne
fuldstændig løbsk-løbne diskussion...

Andreas Plesner Jaco~ (12-06-2001)
Kommentar
Fra : Andreas Plesner Jaco~


Dato : 12-06-01 08:04

In article <9g3ogr$2ohn$1@news.cybercity.dk>, Gigasoft Danmark wrote:
>
>> Jeg kan ikke lide, at begge de kodede dokumenter starter med samme
>> bogstav som klarteksten. Det giver mig en mistanke om, at din
>> hashing rammer en svag nøgle (eller indekserer du forkert, så
>> krypteringen først starter ved andet tegn?).
> Jeg ved ikke om jeg egentligt burde skrive dette. Men...
> Koden er oprindelig udviklet i Kina (Ja grin bare men det er sandt)

Nej, RC4 er udviklet af Ron Rivest for RSA Data Security.

--
Andreas Plesner Jacobsen | Did I say 2? I lied.

Jonathan Stein (12-06-2001)
Kommentar
Fra : Jonathan Stein


Dato : 12-06-01 22:40

Gigasoft Danmark wrote:

> > Jeg kan ikke lide, at begge de kodede dokumenter starter med samme bogstav
>
> > som klarteksten. Det giver mig en mistanke om, at din hashing rammer en svag
>
> > nøgle (eller indekserer du forkert, så krypteringen først starter ved andet
> > tegn?).
> Jeg ved ikke om jeg egentligt burde skrive dette. Men...
> Koden er oprindelig udviklet i Kina (Ja grin bare men det er sandt)
> Deres alfabet er så væsentlig anderleds end vores at det kan give nogle
> sådanne ressultater.

Hvor i alverden har du det fra? Skrifttegnene har intet med det at gøre -
kodningen foregår på binære data. (Og så var algoritmen jo altså udviklet i
USA).

> Derefter er den blevet vestliggjort af et hold Amerikanere som mente at det
> Kinesiske sprog for en vesterlænding næsten i sig selv er en fantastik
> kryptering.

Oversætter algoritmen fra engelsk til kinesisk? - Ellers har dette da _ingen_
relevans for algoritmen.

> De virkelige eksperter er her. Det er helt sikker.
> Kinesere, Amerikanere, Australiere, Russere og andet godtfolk kan godt pakke
> sammen.

Fornemmer jeg en hvis sarkasme? Samtidig med at du mener, at du kan udvikle en
algoritme, som ingen kan bryde...

> > Hvad jeg ser som et større problem er, at mange af de nye funktioner, du
> > lægger vægt på, kræver en hemmelig krypteringsalgoritme.
>
> Ja , men jeg kan ikke se hvorfor det skulle være så stort et problem.

Det har jeg ellers prøvet at sige før. Enten skal du udvikle en helt ny
algoritme. Da du allerede har sagt, at du ikke beskæftiger dig med kryptering,
formoder jeg, at denne mulighed er udelukket. Ellers skal du vælge en kendt
algoritme og så undlade at fortælle hvilken algoritme, du har valgt. Det vil dog
meget let kunne afgøres ved at kigge lidt på dit program i en debugger.

> Det største problem er da at hvis jeg ikke udlevere koden siger nogle at så
> stoler de ikke på systemet, og når jeg så udleverer den siger andre at nu
> stoler de ikke på sikkerheden for nu kender alle koden.
>
> Hvordan skal jeg gøre alle tilfredsse?

Der er kun én måde: Udvikle et system, som fungerer selv om algoritmen er
kendt!

> Nu kan ingen udlever krypteringsalgoritmen, for ingen ville kende den.

Du kender den! Kan du bestikkes eller trues til at udlevere den? Sikkerheden i
dit program er ikke større end sikkerheden for, at du på et tidspunkt vil svare
ja til dette spørgsmål.

> > Har du evner til at skrive en sikker algoritme, der ikke kan findes ved
> > lave reverse-engineering på programmet?
> Ikke hvis jeg skal stole på denne gruppes bedømmelse af mine evner. Men jeg
> kender folk der kan.

Hvordan vil du (eller andre) forhindre, at man kan reverse-engineere sig til
algoritmen?

> >Hvis du vælger en eksisterende
> > algoritme, er det formentlig kun et spørgsmål om tid før nogen gætter
> > hvilken algoritme, der anvendes.
>
> Ja men min ide er også at den skulle variere afhængig af nøglen.

Det vil som andre har påpeget blot resultere i en ny algoritme med større
kompleksitet.

> Altså hvis man bruger den samme algoritme begge eller flere gange men
> forskudt eller med flere forskellige nøgler.

Umiddelbart vil jeg tro, at det giver større effekt at bruge krudtet på
længere nøgler.

> Er der f.eks nogen der på en skala fra 1 til 10 kan sige mig hvor sikker min
> algoritme er som jeg offentliggjorde her tidligere, og komme med et bud på
> hvor lang tid en uautiseret dekryptering ville kunne tage.

RC4 med 40 bit er brudt på omkring en uge. Efter sigende også kortere tid. Et
af problemerne er, at 1 ud 256 nøgler kan brydes væsentligt hurtigere.

M.v.h.

Jonathan

--
jsp-hotel.dk tilbyder profesionelle webhoteller med bl.a. Resin JSP,
PHP, MySQL, SSH/Telnet adgang, rå log-filer, grafisk statistik og
99% oppetidsgaranti.
http://www.jsp-hotel.dk/





Gigasoft Danmark (13-06-2001)
Kommentar
Fra : Gigasoft Danmark


Dato : 13-06-01 00:04


"Jonathan Stein" <jstein@image.dk> wrote in message
news:3B268C45.A25E2148@image.dk...

> Der er kun én måde: Udvikle et system, som fungerer selv om algoritmen
er
> kendt!

Al andet lige, så må det da være noget vanskeligere at gå i gang med at
kracke et system hvor man ikke kender koden end på et system hvor man kender
det.

Og når man snakker kryptering handler det jo altid om tid.
Dets længere et system kan holde på hemmelighederne dets mere sikkert er
det.

Det første jeg ville gøre hvis jeg skulle bryde et krypteret dokument ville
da være at studere den anvendte kode grundigt inden jeg gik i gang med at
kode et angreb.

Apropo sikkerhed,
Har lige i et nyhedsbrev læst at nu er nogle forretninger klar til at kunne
modtage betaling via mobil telefonen i sted for F.eks Dankort..

Her er et udsnit af nyhedsbrevet.

Orange klar med mobil betaling
Som det første selskab tilbyder Orange nu sine kunder at betale med
mobiltelefonen. Foreløbig er otte butikker tilmeldt ordningen.
http://www.computerworld.dk/vis_artikel.asp?ArticleID=11010


Det må da virkeligt være noget der kræver et sej sikkerhedssystem.
Tror du de vil udleve koderne til dette ?

Jeg tvivler altså.

Og jeg får sved på panden bare ved at tænke på hvad et sådant
sikkerhedssystem skal kunne stå for.


--
Med venlig hilsen
Gigasoft Danmark
Bjarne Østergård
www.gigasoft.dk E-mail: boe@gigasoft.dk
Tlf. 86 49 64 04









Andreas Plesner Jaco~ (13-06-2001)
Kommentar
Fra : Andreas Plesner Jaco~


Dato : 13-06-01 08:49

In article <9g67iu$5og$1@news.cybercity.dk>, Gigasoft Danmark wrote:
>
>> Der er kun én måde: Udvikle et system, som fungerer selv om
>> algoritmen er kendt!
>
> Al andet lige, så må det da være noget vanskeligere at gå i gang med at
> kracke et system hvor man ikke kender koden end på et system hvor man kender
> det.

Men du skal kun konstatere, hvilken algoritme der er brugt en gang,
derfor er det vigtigt at sikkerheden ligger i nøglen og
nøgleudvekslingen.

> Apropo sikkerhed,
> Har lige i et nyhedsbrev læst at nu er nogle forretninger klar til at kunne
> modtage betaling via mobil telefonen i sted for F.eks Dankort..
>
> Det må da virkeligt være noget der kræver et sej sikkerhedssystem.
> Tror du de vil udleve koderne til dette ?

Der er stor forskel på koderne og algoritmerne.
SVJV er algoritmerne der benyttes i GSM systemer offentligt
tilgængelige.

--
Andreas Plesner Jacobsen | To err is human,
| To purr feline.
|    -- Robert Byrne

Lasse Reichstein Nie~ (13-06-2001)
Kommentar
Fra : Lasse Reichstein Nie~


Dato : 13-06-01 10:46

"Gigasoft Danmark" <boe@gigasoft.dk> writes:

> "Jonathan Stein" <jstein@image.dk> wrote in message
> news:3B268C45.A25E2148@image.dk...
>
> > Der er kun én måde: Udvikle et system, som fungerer selv om algoritmen
> er
> > kendt!
>
> Al andet lige, så må det da være noget vanskeligere at gå i gang med at
> kracke et system hvor man ikke kender koden end på et system hvor man kender
> det.

Ja, men ikke betydeligt. Først finder man ud af hvilken algoritme der
bruges, og til det kan man passende disassemble dit program og sætte
et par maskine-kode-nørder til at læse det. Det tager vel en højest en
uges tid hvis man vikrelig mener det.

> Og når man snakker kryptering handler det jo altid om tid.
> Dets længere et system kan holde på hemmelighederne dets mere sikkert er
> det.

Ja, fire millioner år er bedre end fire tusinde år, men 7 dage fra eller
til, som oven i købet er en engangs-indsats, derefter er algoritmen
kendt, gør altså ikke nogen forskel for folk der både vil og kan
bryde kryptering. At holde algoritmen hemmelig giver højest falsk
sikkerhed. Hvis sikkerheden er afhængig af at algoritmen er hemmelig,
så er sikkerheden ubrugelig. Derfor mistænkes alle der holder deres
algoritmer hemmelige for at have systemer der ikke kan tåle at de
er offentlige, så derfor regnes de som ubrugelige. Inden for sikkerhed
regnes alt for usikkert til det modsatte er sandsynliggjort (intet kan
bevises :). Der er ikke noget der hedder 95% sikker.

> Det første jeg ville gøre hvis jeg skulle bryde et krypteret dokument ville
> da være at studere den anvendte kode grundigt inden jeg gik i gang med at
> kode et angreb.

Ja, første gang. Hvis der ikke allerede er en der har gjort det og
skrevet resultatet på internet.

/L
--
Lasse Reichstein Nielsen - lrn@daimi.au.dk
This message may be reproduced freely for non commercial purposes.
"... but where do you want to go tomorrow?"

Klaus Ellegaard (13-06-2001)
Kommentar
Fra : Klaus Ellegaard


Dato : 13-06-01 16:05

On Wed, 13 Jun 2001 01:03:56 +0200, Gigasoft Danmark <boe@gigasoft.dk> wrote:
> Al andet lige, så må det da være noget vanskeligere at gå i gang med at
> kracke et system hvor man ikke kender koden end på et system hvor man kender
> det.

Hvorfor det?

Hvis du opdager en algoritme i et program, som erfaringsmæssigt ikke
kan knækkes på selv de kraftigste computere, så kan du lige så godt
opgive dér. (Næsten i hvert fald. Der er altid en mulighed/risiko
for, at der er fejl i implementeringen, der gør det nemt).

Spørgsmålet er også, hvad det er, der er krypteret. Nu snakker du så
meget om "top secret". Hvis det virkelig er noget, der rykker, er
det ikke usandsynligt, at nogen vil bruge rigtigt mange kræfter på
problemet. Det er der nok ikke mange hjemmebryggede algoritmer, der
kan stå imod i længden. Men dermed ikke sagt at det er umuligt.

> Orange klar med mobil betaling
> Som det første selskab tilbyder Orange nu sine kunder at betale med
> mobiltelefonen. Foreløbig er otte butikker tilmeldt ordningen.
> http://www.computerworld.dk/vis_artikel.asp?ArticleID=11010
>
> Det må da virkeligt være noget der kræver et sej sikkerhedssystem.
> Tror du de vil udleve koderne til dette ?

Ja, hvorfor ikke?

> Og jeg får sved på panden bare ved at tænke på hvad et sådant
> sikkerhedssystem skal kunne stå for.

Helt ærligt - det er da grænsende til det ligegyldige. Selvfølgelig
skal der være tale on en fornuftig kryptering, men hvorfor kaste
kræfter efter at lave den selv? Hvorfor ikke bruge en offentligt
tilgængelig algoritme, der har vist sig at være praktisk ubrydelig?

Snakker vi beskyttelse af forbrugeren, er han i forvejen er dækket
af betalingskortloven (som sikkert også dækker her?). Den friholder
forbrugeren i de fleste tilfælde, så det er "kun" Orange, der
risikerer noget her.

Transporten er allerede dækket af GSMs kryptering, som langt fra
er ubrydelig, men som stort set alle forbrugere har tillid til;
tænk blot på den mængde forretningsfolk der diskuterer hemmelige
ting og sager via mobiltelefonen.

Kommunikationen mellem Orange og butikken er ret ukritisk, hvis
vi snakker kunder, der er koblet op via Oranges eget netværk -
her er det i teorien kun Oranges egne medarbejdere, der kan være
kilden til et problem. Det problem skal man ikke undervurdere
(generelt altså - det er ikke ment som en kritik af Orange på
nogen måde), men igen: risikomomentet er forholdsvis begrænset.

Så snart du rammer kundens (butikkens) netværk, er det butikkens
problem og ansvar. Og hvordan er butikkens netværk og computere
beskyttet i forhold til algoritmen? Hvis deres computere kan
hackes, kan man også finde detaljer om algoritmen og ikke mindst
transaktionsdata i klartekst på den (i hvert fald i de øjeblikke
hvor selve informationen behandles).

Skulle det så endelig gå galt, skal Orange formentlig friholde
både butikken og butikkens kunde for skade. Hvordan vil denne
potentielle risiko stå mål med en meget kostbar, egenudviklet
kryptering, når der findes nogle helt gratis og sikkert bedre?

Alt i alt: hvor er det lige, der er brug for en så alvorlig
kryptering, og hvad er det, du får sved på panden over?

Mvh.
   Klaus.

Jonathan Stein (13-06-2001)
Kommentar
Fra : Jonathan Stein


Dato : 13-06-01 22:01

Gigasoft Danmark wrote:

> > Der er kun én måde: Udvikle et system, som fungerer selv om algoritmen er
> > kendt!
>
> Al andet lige, så må det da være noget vanskeligere at gå i gang med at
> kracke et system hvor man ikke kender koden end på et system hvor man kender
> det.

Måske - hvis krypteringen er "ubrydelig" er det jo ligemeget, om man kender
algoritmen. Om det tager 10 mio. år eller 10 mio. år og 8 dage er nok
ligegyldigt for de fleste.

> Orange klar med mobil betaling
> ...
> Det må da virkeligt være noget der kræver et sej sikkerhedssystem.
> Tror du de vil udleve koderne til dette ?

Koderne: Nej (ikke den hemmelige del - mon ikke der er noget public key med i
spillet).
Algoritmen: Jo! Bl.a. bankerne anvender offentligt kendte
krypteringsalgoritmer, så hvorfor skulle Orange ikke også gøre det.

M.v.h.

Jonathan

--
jsp-hotel.dk tilbyder profesionelle webhoteller med bl.a. Resin JSP,
PHP, MySQL, SSH/Telnet adgang, rå log-filer, grafisk statistik og
99% oppetidsgaranti.
http://www.jsp-hotel.dk/





Per H. Nielsen (14-06-2001)
Kommentar
Fra : Per H. Nielsen


Dato : 14-06-01 08:21

Jonathan Stein <jstein@image.dk> writes:

>Gigasoft Danmark wrote:

>> Al andet lige, så må det da være noget vanskeligere at gå i gang med at
>> kracke et system hvor man ikke kender koden end på et system hvor man kender
>> det.

> Måske - hvis krypteringen er "ubrydelig" er det jo ligemeget, om man kender
>algoritmen. Om det tager 10 mio. år eller 10 mio. år og 8 dage er nok
>ligegyldigt for de fleste.

De 8 dage er nok meget realisk her. Vi taler jo om systemer,
hvor den, der vil forsøge at bryde krypteringen, højst
sandsynligt vil have adgang til programmet, der med den
rigtige nøgle kan foretage afkrypteringen.
Med passende brug af disassembler og debugger kan selve
virkemåden af programmet (og hermed krypteringsalgoritmen)
derfor blotlægges.

Sikkerheden i et nøglebaseret krypteringssystem skal ligge i de anvendte
nøgler ikke i hemmeligholdelse af algoritmer. Man må for alt
i verden ikke forfalde til brug af "security through obscurity".

Hilsen
Per

--
Per H. Nielsen <phn@dkscan.dkx>
My Danish Scanner Pages: http://www.dkscan.dk
To reply to this change .dkx to .dk in my address.

Jesper Stocholm (17-06-2001)
Kommentar
Fra : Jesper Stocholm


Dato : 17-06-01 22:51

Jonathan Stein <jstein@image.dk> wrote in
news:3B268C45.A25E2148@image.dk:

> Gigasoft Danmark wrote:
>
>> Altså hvis man bruger den samme algoritme begge eller flere gange men
>> forskudt eller med flere forskellige nøgler.
>
> Umiddelbart vil jeg tro, at det giver større effekt at bruge krudtet
> på
> længere nøgler.
>

det er også korrekt. Et klassisk eksempel er en tekst, der er krypteret to
gange med to forskellige 128-bits nøgler. Det vil simpelt betragtet kræve en
dekryptering af den første omgang - dvs bryde 128-bits kryptering ... og
dereefter endnu en omgang dekryptering/crack af den "inderste" nøgle. Dette
giver med andre ord et maksimalt arbejde på 2*2^128 operationer ... hvilket
normalt regnes som værende det samme.

eller lidt mere formelt : O(2*2^128) = 2*O(2^128) =~ O(2^128)


--
I wrote to George W. Bush - see why at
http://stocholm.dk/emailgeorgewbush.asp

- Jesper Stocholm - http://stocholm.dk

Jonathan Stein (19-06-2001)
Kommentar
Fra : Jonathan Stein


Dato : 19-06-01 08:41

Jesper Stocholm wrote:

> eller lidt mere formelt : O(2*2^128) = 2*O(2^128) =~ O(2^128)

O(2*2^128) = O(2^129)

- Det svarer altså til, at man krypterer med én bit mere...

M.v.h.

Jonathan

--
jsp-hotel.dk tilbyder profesionelle webhoteller med bl.a. Resin JSP,
PHP, MySQL, SSH/Telnet adgang, rå log-filer, grafisk statistik og
99% oppetidsgaranti.
http://www.jsp-hotel.dk/





Jesper Stocholm (19-06-2001)
Kommentar
Fra : Jesper Stocholm


Dato : 19-06-01 17:30

Jonathan Stein <jstein@image.dk> wrote in news:3B2F0206.21CB406A@image.dk:

> Jesper Stocholm wrote:
>
>> eller lidt mere formelt : O(2*2^128) = 2*O(2^128) =~ O(2^128)
>
> O(2*2^128) = O(2^129)
>
> - Det svarer altså til, at man krypterer med én bit mere...
>

... men det er kun fordi 2 tilfældigvis er det samme som rodtallet.
Generelt er det

O(k*2^128) = k*O(2^128) =~ O(2^128)

--
I wrote to George W. Bush - see why at
http://stocholm.dk/emailgeorgewbush.asp

- Jesper Stocholm - http://stocholm.dk

Jonathan Stein (19-06-2001)
Kommentar
Fra : Jonathan Stein


Dato : 19-06-01 18:41

Jesper Stocholm wrote:

> > - Det svarer altså til, at man krypterer med én bit mere...
>
> ... men det er kun fordi 2 tilfældigvis er det samme som rodtallet.
> Generelt er det
>
> O(k*2^128) = k*O(2^128) =~ O(2^128)

Nu er 2^128 jo også en konstant (omend temmelig stor), så O(2^128) = O(k) ~
O(1)

Det afgørende er O(2^n), hvor n er nøglelængden, så det vi egentlig sidder
og siger til hinanden er, at O(2^n) ~ O(2^(n+1)) - i hvert fald, når n ikke er
alt for lille.

M.v.h.

Jonathan

--
jsp-hotel.dk tilbyder profesionelle webhoteller med bl.a. Resin JSP,
PHP, MySQL, SSH/Telnet adgang, rå log-filer, grafisk statistik og
99% oppetidsgaranti.
http://www.jsp-hotel.dk/





Jesper Stocholm (19-06-2001)
Kommentar
Fra : Jesper Stocholm


Dato : 19-06-01 22:09

Jonathan Stein <jstein@image.dk> wrote in
news:3B2F8E9D.AEFA7DC2@image.dk:

> Jesper Stocholm wrote:
>
>> > - Det svarer altså til, at man krypterer med én bit mere...
>>
>> ... men det er kun fordi 2 tilfældigvis er det samme som
>> :rodtallet.
>> Generelt er det
>>
>> O(k*2^128) = k*O(2^128) =~ O(2^128)
>
> Nu er 2^128 jo også en konstant (omend temmelig stor), så O(2^128) =
> O(k) ~
> O(1)
>
> Det afgørende er O(2^n), hvor n er nøglelængden, så det vi egentlig
> sidder
> og siger til hinanden er, at O(2^n) ~ O(2^(n+1)) - i hvert fald, når n
> ikke er alt for lille.
>

mjaeh ... det afgørende er funktionen, der for et givet input beskriver det
nødvendige arbejde for at løse opgaven - altså i dette tilfælde 2^n ... at
der så er faktorer foran og evt konstanter lagt til er for så vidt
ligegyldigt.

Komplexiteten f(n) = 2^n + 10^400 vil faktisk også blive regnet som f(n) = 2
^n ... selvom 10^400 i tilfældet n=128 faktisk er meget størrre end 2^128

--
I wrote to George W. Bush - see why at
http://stocholm.dk/emailgeorgewbush.asp

- Jesper Stocholm - http://stocholm.dk

Jonathan Stein (19-06-2001)
Kommentar
Fra : Jonathan Stein


Dato : 19-06-01 22:57

Jesper Stocholm wrote:

> > Nu er 2^128 jo også en konstant (omend temmelig stor), så
> > O(2^128) = O(k) ~ O(1)
> >
> > Det afgørende er O(2^n), hvor n er nøglelængden, så det vi egentlig sidder
>
> > og siger til hinanden er, at O(2^n) ~ O(2^(n+1)) - i hvert fald, når n
> > ikke er alt for lille.
>
> mjaeh ... det afgørende er funktionen, der for et givet input beskriver det
> nødvendige arbejde for at løse opgaven - altså i dette tilfælde 2^n ... at
> der så er faktorer foran og evt konstanter lagt til er for så vidt
> ligegyldigt.
>
> Komplexiteten f(n) = 2^n + 10^400 vil faktisk også blive regnet som f(n) = 2
> ^n ... selvom 10^400 i tilfældet n=128 faktisk er meget størrre end 2^128

Hmm - var det ikke lige det, jeg skrev? At 2^128 er en konstant og derfor
uinteressant for kompleksiteten, og at det derfor var 2^n, som var afgørende...

M.v.h.

Jonathan

--
jsp-hotel.dk tilbyder profesionelle webhoteller med bl.a. Resin JSP,
PHP, MySQL, SSH/Telnet adgang, rå log-filer, grafisk statistik og
99% oppetidsgaranti.
http://www.jsp-hotel.dk/




Jesper Stocholm (20-06-2001)
Kommentar
Fra : Jesper Stocholm


Dato : 20-06-01 08:57

Jonathan Stein <jstein@image.dk> wrote in
news:3B2FCA9D.245ECD75@image.dk:

> Jesper Stocholm wrote:
>
>> > Nu er 2^128 jo også en konstant (omend temmelig stor), så
>> > O(2^128) = O(k) ~ O(1)
>> >
>> > Det afgørende er O(2^n), hvor n er nøglelængden, så det vi
>> > egentlig sidder
>>
>> > og siger til hinanden er, at O(2^n) ~ O(2^(n+1)) - i hvert fald, når
>> > n ikke er alt for lille.
>>
>> mjaeh ... det afgørende er funktionen, der for et givet input
>> beskriver det nødvendige arbejde for at løse opgaven - altså i dette
>> tilfælde 2^n ... at der så er faktorer foran og evt konstanter lagt
>> til er for så vidt ligegyldigt.
>>
>> Komplexiteten f(n) = 2^n + 10^400 vil faktisk også blive regnet som
>> f(n) = 2 ^n ... selvom 10^400 i tilfældet n=128 faktisk er meget
>> størrre end 2^128
>
> Hmm - var det ikke lige det, jeg skrev? At 2^128 er en konstant og
> derfor
> uinteressant for kompleksiteten, og at det derfor var 2^n, som var
> afgørende...
>

jo ... det skrev du faktisk.

hmmm ... en af disse dage skal jeg altså have lært at læse ...

--
I wrote to George W. Bush - see why at
http://stocholm.dk/emailgeorgewbush.asp

- Jesper Stocholm - http://stocholm.dk

Niels Teglsbo (19-06-2001)
Kommentar
Fra : Niels Teglsbo


Dato : 19-06-01 22:42

spam@stocholm.dk (Jesper Stocholm) wrote:

> eller lidt mere formelt : O(2*2^128) = 2*O(2^128) =~ O(2^128)

Det giver vist mest mening af udregne tidskompleksiteten som funktion af
nøglelængden n og antallet af krypteringer med nøglen i.

Så er tidskompleksiteten for udtømmende søgning
O(i*2^n) eller O( 2^(n + lg(i)) ) hvor lg er totalslogaritmen.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo
PGP ID: 0x79701FB3 FP: 14CE E6BA 29CC 4ECE D7A3 30D3 FB74 A1CB 7970 1FB3

Søg
Reklame
Statistik
Spørgsmål : 177501
Tips : 31968
Nyheder : 719565
Indlæg : 6408528
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste