Αρχικοποιηση μυστικης ηλεκτρονικης ψηφοφοριας & η γεννηση ιδεας

[random]

ή κάπως έτσι τέλος πάντων....

πές μου πως παράγεις το ένα hash από το ένα plaintext, να σου πω πως θα φτιάξεις το μαζικό.

την εντολή που παράγει ένα hash την πήρα από εδώ.

[random]

Έχουμε μια λίστα από plaintext passwords, και μπορούμε με ένα key να παράγουμε τα αντίστοιχα hashes.
Ή μπορούμε για κάθε plaintext, να παράγουμε το hash με διαφορετικό key.

Αυτό σημαίνει βέβαια ότι έχει γίνει μια παράλληψη στον αλγόριθμο.
Δεν αρκεί να βάλουμε το plaintext password στο φάκελο, πρέπει να βάλουμε και το key με το οποίο παράγουμε το hash, για να μπορεί ο σύνεδρος που θα λάβει τον φάκελο να είναι σε θέση από το το plaintext να παράγει το hash.

Νομίζω το πράγμα μπλέκει αρκετά.....όχι από την πλευρά του συνέδρου, αυτός ένα plaintext password θα εισάγει πάλι. Αλλά από τον κώδικα που πρέπει να γραφτεί, κώδικας που θα τρέχει στον υπολογιστή του σύνεδρου όταν ψηφίζει που θα παράγει το hash με βάση το κλειδί που έλαβε στο φάκελο και φρόντισε να το αποθηκεύσει κάπου στον υπολογιστή του. Με το hash αυτό που θα παράγεται, θα γίνεται στην συνέχεια το authentication με τον server. Ο server δηλαδή θα θεωρεί το hash σαν να είναι password; Δεν ξέρω, κάπου το έχω χάσει μου φαίνεται....

[random]

Αν αποφασίσουμε να παράγουμε όλα τα hashes με μόνο ένα key, τότε το key δεν χρειάζεται να μπει στο φάκελο, το δημοσιεύσουμε να το ξέρουν όλοι.

Φτιάχνουμε το αρχείο που περιέχει τα διάφορα passwords, το ένα κάτω από το άλλο, και το ονομάζουμε myplaintextvalues.

Σε αυτή την περίπτωση ο κώδικας για παραγωγή μαζικών hashes από ένα key γίνεται.

Κώδικας: Επιλογή όλων

values=`cat myplaintextvalues`
for v in $values
do
echo -n "$v" | openssl dgst -sha1 -hmac "key" >> myhashes
done

[random]

Δηλαδή αν κάποιος μάθει το hash με κάποιο τρόπο, δεν μπορεί άνετα μετά να κάνει authenticion με τον server, χωρίς να έχει στην κατοχή του ούτε κλειδί ούτε το plaintext; Τι εξυπηρετεί και σε τί μπορεί να βοηθήσει που ο σύνεδρος έχει στην κατοχή του το key και το plaintext; Πως μπορεί να εμποδίσει τον παραπάνω;

ίσως αυτό βοηθήσει

Simple example mutual-authentication sequence

Server sends a unique challenge value sc to the client
Client generates unique challenge value cc
Client computes cr = hashA(cc + sc + secret)
Client sends cr and cc to the server
Server calculates the expected value of cr and ensures the client responded correctly
Server computes sr = hashB(cc + sc + secret)
Server sends sr
Client calculates the expected value of sr and ensures the server responded correctly

where

sc is the server generated challenge
cc is the client generated challenge
cr is the client response
sr is the server response

Δηλαδή ο σύνεδρος έχει στην κατοχή του plaintext, key και hash
Ενώ στο server έχουμε key και hash μόνο.

Για την περίπτωση που κάποιος κλέψει το hash (το οποίο μεταδίδεται από τον server στον client για το authentication) ίσως κατά το authentication να πρέπει να απαιτηθεί εκτός από την ταυτοποίηση του hash, να γίνεται και ένα mutual-authentication sequence βασισμένο στο key.


Κάπου δεν το έχω ακόμα πλήρως, σε αυτά που είπα με τα hashes, και σε κάθε περίπτωση, ακόμα και αν καταφέρουμε να μην έχει flaws, χρειάζεται σίγουρα και κώδικας όπως το βλέπω .

Όπότε μάλλον βάλε ένα απλό plain text login-pass, χωρίς hashes και τέτοια, και άσε τα διαστημικά για αργότερα να το σκεφτω-εις καλύτερα.

Τελικά με αυτά τα hashes μπλέκουμε, η μέθοδος με το pgp είναι τόσο καλύτερη!!! Τι κρίμα να μην καταλαβαίνει ο κόσμος το pgp.....

[dizzyk]

Αν καταλαβαίνω καλά, το key είναι για την παραγωγή salted hash; Αν είναι έτσι, η λογική είναι η εξής:

Σε ένα απλό plaintext -> hash σχήμα, ο server έχει μόνο το hash, ο user του δίνει το password, και ο server ελέγχει αν το password παράγει αυτό το hash. Αυτό όμως είναι ευάλωτο σε attack με rainbow tables (ο κλασσικός τρόπος να σπάσεις το password των windows, πολύ χρήσιμο όταν ο πρώην admin έχει μεταναστεύσει). Η λύση είναι τα salted hashes, όπου προστίθεται ένα επιπλέον κλειδί στο password πριν βγει το hash και μπορεί να είναι διαφορετικό για κάθε user. Αυτό εκτός του ότι ανεβάζει τη δυσκολία του να φτιαχτεί ένα καλό rainbow table δεν επιτρέπει τη μαζική ανάκτηση password από ένα σύστημα γιατί θέλει διαφορετικό rainbow table για κάθε χρήστη.

[James]

Έχω την εντύπωση ότι όλα αυτά δε βοηθούν στη περίπτωση τη δική μας.
Μέ μία απλή διαδικασία login in ή οποία να έχει και ένα δεύτερο επίπεδο αυθεντικόποίησης (ερώτηση ασφαλείας) για την είσοδο του χρήστη.
Ολα τα παραπάνω έχουν να κάνουν με κρυπτογραφίσεις άλλου επιπέδου.
Το δικό μας σύστημα πρέπει να είναι απλό μεν, ασφαλές δε, δε διακυβεύονται κρατικά μυστικά.
Το όλο θέμα έχει να κάνει με τη διαχείριση, αν υπάρχει εμπιστοσύνη στους διαχειριστές δεν έχουμε πρόβλημα.
Και ας ξεκινήσουμε έτσι απλά και στη πορεία να δούμε πως μπορούμε να συνδέσουμε κάποια υπηρεσία με δημόσια υπογραφή πχ ΕΡΜΗΣ.

[random]

Αν καταλαβαίνω καλά, το key είναι για την παραγωγή salted hash; Αν είναι έτσι, η λογική είναι η εξής:

Σε ένα απλό plaintext -> hash σχήμα, ο server έχει μόνο το hash, ο user του δίνει το password, και ο server ελέγχει αν το password παράγει αυτό το hash. Αυτό όμως είναι ευάλωτο σε attack με rainbow tables (ο κλασσικός τρόπος να σπάσεις το password των windows, πολύ χρήσιμο όταν ο πρώην admin έχει μεταναστεύσει). Η λύση είναι τα salted hashes, όπου προστίθεται ένα επιπλέον κλειδί στο password πριν βγει το hash και μπορεί να είναι διαφορετικό για κάθε user. Αυτό εκτός του ότι ανεβάζει τη δυσκολία του να φτιαχτεί ένα καλό rainbow table δεν επιτρέπει τη μαζική ανάκτηση password από ένα σύστημα γιατί θέλει διαφορετικό rainbow table για κάθε χρήστη.

όχι δεν καταλαβαίνεις καλά.
εμείς δεν θέλουμε να δώσουμε το plaintext password στον server, θέλουμε να μην το μάθει κανείς, ούτε ο server, ούτε κάποιος ενδιάμεσος στην διαδρομή..
θέλουμε το plaintext password να πληκτρολογήται στον υπολογιστή του σύνεδρου από τον σύνεδρο, να επεξεργάζεται τοπικά μαζί με το key, να παράγεται τοπικά το hash, και να στέλνεται το hash στο δίκτυο και στον server. Και μόλις το λάβει ο server, να κάνει mutual-authentication sequence και στην συνέχεια να δέχεται τον σύνεδρο.

[James]

Ναι ρε random
Αλλά αν υπάρχουν στο σερβερ τα hash κάποια στιγμή με rainbow tables μπορεί ο κακόβουλος διαχειριστής ή εισβολέας να γυρίσει το hash και να κάνει μαζική είσοδο.

[random]

Έχω την εντύπωση ότι όλα αυτά δε βοηθούν στη περίπτωση τη δική μας.
Μέ μία απλή διαδικασία login in ή οποία να έχει και ένα δεύτερο επίπεδο αυθεντικόποίησης (ερώτηση ασφαλείας) για την είσοδο του χρήστη.
Ολα τα παραπάνω έχουν να κάνουν με κρυπτογραφίσεις άλλου επιπέδου.
Το δικό μας σύστημα πρέπει να είναι απλό μεν, ασφαλές δε, δε διακυβεύονται κρατικά μυστικά.
Το όλο θέμα έχει να κάνει με τη διαχείριση, αν υπάρχει εμπιστοσύνη στους διαχειριστές δεν έχουμε πρόβλημα.
Και ας ξεκινήσουμε έτσι απλά και στη πορεία να δούμε πως μπορούμε να συνδέσουμε κάποια υπηρεσία με δημόσια υπογραφή πχ ΕΡΜΗΣ.

Αυτό που περιγράφω με τα hashes, από την μεριά του σύνεδρου αυτό ακριβώς είναι, μια απλή διαδικασία login. Απόπισω μπορεί να παίζουν παπάδες κώδικα, αλλά αυτός δεν το καταλαβαίνει.

To ερμής είναι άλλη κατάσταση, τα κλειδιά δεν τα αποφασίζεις εσύ, σου τα δίνει ο ερμής. Το ερμής είναι χρήσιμο αν θέλουμε να είμαστε νόμιμοι σύμφωνα με την πολιτεία.

Το απόλυτα ασφαλές όμως και δίκαιο δεν είναι το ερμής, αλλά η συνάντηση κλειδιών. Εκεί ο κάθε σύνεδρος παίρνει την ασφάλειά του στα χέρια του, δεν εξαρτάται από την τιμιότητα του διαχειριστή του συστήματος ερμής.

[random]

Ναι ρε random
Αλλά αν υπάρχουν στο σερβερ τα hash κάποια στιγμή με rainbow tables μπορεί ο κακόβουλος διαχειριστής ή εισβολέας να γυρίσει το hash και να κάνει μαζική είσοδο.

Εγώ δεν λέω όχι, απλά δεν καταλαβαίνετε ότι αυτή την στιγμή συζητάμε το πρωτόκολλο, και όχι την ασφάλεια του hash.
Η ασφάλεια του hash είναι άλλο πρόβλημα.