[an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]
 
[an error occurred while processing this directive] [an error occurred while processing this directive]
Skåne Sjælland Linux User Group - http://www.sslug.dk Home   Subscribe   Mail Archive   Forum   Calendar   Search
MhonArc Date: [Date Prev] [Date Index] [Date Next]   Thread: [Date Prev] [Thread Index] [Date Next]   MhonArc
 

Silkkerhed i one-way hash funktioner



der findes ikke nogen "invers" funktion til en hash funktion, jf navnet.
Det er netop deri sikkerheden ligger.

For at være helt præcis så er sandsynligheden for en "kollision" (når to
forskellige tekster giver samme hash) er meget lille. Dvs. sandsynligheden
for at to forskellige cprnumre hashed giver samme PID er meget lille. Derfor
kunne en hash funktion saktens være en god kandidatfunktion til den CA
specifikke del af PID nummeret.

Men en fortløbende tæller har jo en dejligt forudsigelig følge - det er jo
ikke specielt svært at gætte "næste" nummer i rækken.

Hvis man antager brute-force angreb på en fortløbende tæller er søgerummet
MEGET mindre end en moderne hashfunktion, dvs. sikkerheden ved brug af hash
er derfor meget bedre.

/Bo
http://bofriis.dk

"Guldberg,Jørn JGU" <sslug@sslug> wrote in message
news:sslug@sslug


> Anna Jonna Armannsdottir <sslug@sslug> writes:
>
> > søn, 2002-07-07 kl. 11:47 skrev Arne Jørgensen:
> >
> >> Jamen ... Sammenhængen mellem PID og CPR-nummer findes vel kun i en
> >> database hos KMD-CA og den har du ikke adgang til.

Korrekt - En af poienterne er, at selvom teorien siger at cracking kan lade
sig gøre, er der en praktisk forudsætning, nemlig at man har mulighed for at
verificere, at man har nået målet. Mao. selvom det lykkedes at finde det
rigtige CPR nummer, hvordan kan du så vide at du fandt det?
Jeg har tidligere givet opgaven, find mit CPR nummer -  men....
Hvorledes skal man vide at det rigtige mål er nået? -

Alle de muligheder jeg kender, anvender anticracking metoder, som tidsstraf
og begrænset antal forsøg. Men den menneskelige opfindsomhed er stor, så jeg
hører meget gerne om måder til at omgå dette.

>
> [klip]
>
> > PID-nummeret er formodentlig dannet fra en "one way hash"
> af de samlede
> > oplysninger der består af CPR-nummer plus yderligere oplysninger.
>
> Du antager altså at der eksisterer en matematisk sammenhæng mellem
> CPR-nummer og PID. Jeg skal da ærligt indrømme at jeg ikke aner
> hvordan PID laves, men det har i hvert fald været min opfattelse at en
> sådan sammenhæng ikke eksisterer (og dermed er brute force cracking
> ikke muligt). Jeg kan naturligvis tage fejl.

Der er ikke nogen grund til at anvende en funktion til at danne PID numre
udfra CPR nummeret. Det ville som Anne angiver, skabe basis for at finde den
inverse funktion.  Det eneste rigtige er en randomfunktion. Specielt når man
tager det begrænsede udfaldsrum ( 20-25 Mio - der er lidt flere end du
regner dig frem til) i betragtning.



>
> > Samtidig vil jeg gøre opmærksom på at denne form for
> "cracking" ville
> > være fuldt lovlig idet certifikaterne er offentliggjorte
> oplysninger og
> > CPR-numre ikke er hemmelige oplysninger eller på anden måde
> anses for at
> > være personfølsomme oplysninger.
>
> Jeg tror nu nok CPR-nummer opfattes som en personfølsom oplysning.
>

CPR numre betragtes som "fortrolige" og " personfølsomme", ifølge
datatilsynet. De må således ikke sendes over Internettet uden at de er
krypteret med mindst 128 Bit kryptering. Det er hele baggrunden for at PID
numrene opstod - det blev diskuteret i FDS i over et År, hvorledes man kunne
sikre både, at der er en unik identitet i certifikatet, samtidigt med, at
CPR nummeret ikke på nogen måde blev offentliggjort.

> mvh
>         /arne

>

Yderligere et aspekt - sikkerhed er et relativt begreb - for enhver
sikkerhedsmekanisme, der opsættes, skal det vurderer hvilken metode, der vil
være angriberens nemmeste vej til at få informationen, der søges.  Den
mekaniske der opsættes, skal naturligvis være mere besværlig, end
alternativerne; men ikke væsentligt mere - således at brugeren ikke belemres
med overflødigt arbejde, med at håndtere en sikkerhed, som kan omgås på
andre måder. Vi kalder det den nødvendige, men tilstrækkelige sikkerhed - og
det forandre sig hele tiden, hvad det er.

Mvh Jørn






 
Home   Subscribe   Mail Archive   Index   Calendar   Search

 
 
Questions about the web-pages to <www_admin>. Last modified 2005-08-10, 20:33 CEST [an error occurred while processing this directive]
This page is maintained by [an error occurred while processing this directive]MHonArc [an error occurred while processing this directive] # [an error occurred while processing this directive] *