OpenSSL questions

[WoLfeN Ilic]

Εχω μερικες αποριες σχετικα με το openSSL και ειπα να τις θεσω μηπως ξερει κανεις
Εχουμε και λεμε:
Υπαρχει τροπος να κρυπτογραφουμε ενα μηνυμα(π.χ Hello) με εναν πιο "αυτοματο" τροπο?Δηλαδη χωρις να χρειαζεται να υπαρχει αρχειο που να περιλαμβανει το κειμενο(καθως η υπαρξη και μονο αρχειου με plain text βαζει σε κινδυνο το ιδιο το μηνυμα σε περιπτωση που καποιος αποκτησει προσβαση στον υπολογιστη)?

Αυτο που θελω να κανω(σε περιπτωση που βοηθαει στην απαντηση), ειναι να φτιαξω ενα script που θα ζηταει απο το χρηστη να πληκτρολογησει το κειμενο που θελει να κρυπτογραφησει, μετα θα του ζηταει(1 φορα) να εισαγει το κλειδι και υστερα θα του εμφανιζει το αποτελεσμα.Επειδη η απαντηση φανταζομαι εξαρταται απο το τι ειδους αλγοριθμο θα χρησιμοποιησουμε, ας πουμε τον aes-256-cbc.
Γνωριζω οτι ετσι κι αλλιως υποστηριζεται interactive mode αλλα δεν με καλυπτει

Και τωρα η δευτερη απορια μου:
Πως μπορω να κανω ενα παρομοιο implementation σε c++?(ιδιος αλγοριθμος, ιδιος τροπος σκεψης)

Thanks εκ των προτερων

[HdkiLLeR]

Nαι προφανώς και γίνεται. Δεν είναι ανάγκη να έχεις το plaintext σου σε κάποιο file και απο εκεί να το κάνεις encrypt. Μπορείς να το διαβάζεις απ' ευθείας απο όπου θέλεις (file, socket, stdin) και να το κάνεις encrypt -- να πάρεις το ciphertext επιτόπου κοινώς. Μπορείς να διαβάζεις το API του OpenSSL ώστε να δεις πως ακριβώς θα κάνεις init το infrastructure που χρειάζεσαι, πως θα περάσεις το IV, το plaintext κλπ κλπ.

Τώρα για την C++ δεν αλλάζεις τπτ, θα κάνεις wrap τα C statements σε κάποια class/classes ανάλογα με το πως είναι δομημένο το application σου.

[WoLfeN Ilic]

Nαι προφανώς και γίνεται. Δεν είναι ανάγκη να έχεις το plaintext σου σε κάποιο file και απο εκεί να το κάνεις encrypt. Μπορείς να το διαβάζεις απ' ευθείας απο όπου θέλεις (file, socket, stdin) και να το κάνεις encrypt -- να πάρεις το ciphertext επιτόπου κοινώς.

ενα παραδειγμα?

[HdkiLLeR]

Πες μου πιο συγκεκριμένα τι ακριβώς θέλεις να κάνεις και θα σε βοηθήσω να το γράψεις -- είμαι ιδιαίτερα lazy αυτόν τον καιρό.

[WoLfeN Ilic]

Πες μου πιο συγκεκριμένα τι ακριβώς θέλεις να κάνεις και θα σε βοηθήσω να το γράψεις -- είμαι ιδιαίτερα lazy αυτόν τον καιρό.

Αυτο που ειπα πιο πανω.Πες οτι εχω ενα c shell script και ζηταω απο τον χρηστη να γραψει μια λεξη που θελει να κρυπτογραφηθει.Την αποθηκευω. Μετα του ζηταω το password. Ε μετα με το openssl κανω encrypt σε aes-256-cbc και του εμφανιζω το αποτελεσμα. Αυτο που θελω να μαθω, ειναι τι παραμετρους πρεπει να δωσω στο openssl ωστε να κανει αυτοματα την ολη διαδικασια

[HdkiLLeR]

Code: Select all

openssl enc -aes-128-cbc -out cipher -e

Σου ζητάει δύο φορές το passphrase για να γίνει το encryption και μετά ότι διαβάσεις απο το stdin το κάνει encrypt (για να σταματήσει πρέπει να δει το EOF (για files) ή το CTRL+D). To passphrase θα γίνει expand σε ένα 128bit key και το plaintext θα κρυπτογραφηθεί με τον AES blockcipher σε CBC mode.

Το encrypted text είναι στο file cipher, μπορείς να το κάνεις cat και θα δεις ότι δεν θα αναγνωρίζεις το text που έδωσες σαν input.

Τώρα για το decrypt κάνεις το εξής:

Code: Select all

openssl enc -aes-128-cbc -in cipher -d

RTFM: http://www.openssl.org/docs/apps/enc.html -- man page enc(1)

[WoLfeN Ilic]

Code: Select all

openssl enc -aes-128-cbc -out cipher -e

Σου ζητάει δύο φορές το passphrase για να γίνει το encryption και μετά ότι διαβάσεις απο το stdin το κάνει encrypt (για να σταματήσει πρέπει να δει το EOF (για files) ή το CTRL+D). To passphrase θα γίνει expand σε ένα 128bit key και το plaintext θα κρυπτογραφηθεί με τον AES blockcipher σε CBC mode.

Το encrypted text είναι στο file cipher, μπορείς να το κάνεις cat και θα δεις ότι δεν θα αναγνωρίζεις το text που έδωσες σαν input.

Τώρα για το decrypt κάνεις το εξής:

Code: Select all

openssl enc -aes-128-cbc -in cipher -d

RTFM: http://www.openssl.org/docs/apps/enc.html -- man page enc(1)

thanks for the reply.
Το ξερω οτι μπορω να κανω κατι τετοιο, αλλα δεν πειραζει μιας και μου ηρθε η ιδεα, να μπορω να περναω εγω μεσω προγραμματος το ctrl+d στο openssl ετσι ωστε οταν ο χρηστης π.χ γραφει "end of message" να θεωρειται σα να πατησε το ctrl+d

[HdkiLLeR]

Το πρόβλημα είναι με το eof? γιατί δεν σου κάνει το παραπάνω directly?

[WoLfeN Ilic]

Το πρόβλημα είναι με το eof? γιατί δεν σου κάνει το παραπάνω directly?

γιατι δε θελω να χρειαζεται να πατησω ctrl+d για να μου βγαλει output :p
strange i know

[HdkiLLeR]

Οκ you know better τι θέλεις να κάνεις και τι σε βολεύει αλλά απο την στιγμή που δίνεις input απο το keyboard το standard convention είναι να κάνεις terminate με CTRL+D. Επίσης δεν θα μπορείς να χρησιμοποιείς I/O redirection και pipelining (<<, <, cat | ...)*

Έχε υπόψην σου ότι στα περισσότερα secure applications το όλο θέμα είναι το integration. Το να κάνεις encrypt όπως είδες ήταν γελοίο. Αρκετοί δεν κατανοούν γιατί όχι ebc mode, καλούν σωστά ένα encryption API αλλά διαβάζουν το password απο το keyboard και το κάνουν store σε ένα απλό variable (που δεν γίνεται ποτέ memset()/bzero()) κλπ κλπ, με αποτέλεσμα το όλο crypto infrastructure που κάνουν utilize να πηγαίνει στον βρόντο .

Εάν θέλεις το συζητάμε και παραπάνω -- κάνε ένα post με τον κώδικα.

*: μπορείς εντάξει αλλά πρέπει να κάνεις on-the-fly rewrite τα streams σου (μάλλον με το tr)

[WoLfeN Ilic]

Οκ you know better τι θέλεις να κάνεις και τι σε βολεύει αλλά απο την στιγμή που δίνεις input απο το keyboard το standard convention είναι να κάνεις terminate με CTRL+D. Επίσης δεν θα μπορείς να χρησιμοποιείς I/O redirection και pipelining (<<, <, cat | ...)*

Έχε υπόψην σου ότι στα περισσότερα secure applications το όλο θέμα είναι το integration. Το να κάνεις encrypt όπως είδες ήταν γελοίο. Αρκετοί δεν κατανοούν γιατί όχι ebc mode, καλούν σωστά ένα encryption API αλλά διαβάζουν το password απο το keyboard και το κάνουν store σε ένα απλό variable (που δεν γίνεται ποτέ memset()/bzero()) κλπ κλπ, με αποτέλεσμα το όλο crypto infrastructure που κάνουν utilize να πηγαίνει στον βρόντο .

Εάν θέλεις το συζητάμε και παραπάνω -- κάνε ένα post με τον κώδικα.

*: μπορείς εντάξει αλλά πρέπει να κάνεις on-the-fly rewrite τα streams σου (μάλλον με το tr)

Oκ ας εξηγησω καλυτερα τι θελω να κανω(δεν εχω ξεκινησει ακομα το γραψιμο κωδικα λογω εξετασεων)
Θελω να φτιαξω ενα προγραμμα που θα μπορει καποιος να κανει chat κρυπτογραφοντας τα μηνυματα του.Οποτε σκεφτομαι να χρησιμοποιησω vbasic για το gui(μιας και opengl δεν ξερω) και c++ για τις διαδικασιες(για linux εκδοσεις, μαλλον θα περιοριστω σε terminal window μεχρι να μαθω κατι αλλο :P).Οποτε ουσιαστικα η vbasic απλα θα στελνει αυτα που κανει ο χρηστης μεσω του gui(αν δηλαδη παταει το κουμπι encrypt text) στην c++ for the dirty work.
Αρα ο χρηστης δεν θελω να εχει καμια επαφη με το τι θα κανει το command prompt απο πισω, οποτε θελω και το προγραμμα σε c++ να κλεινει το stream και να εισαγει και τον κωδικο.
Αυτο ειναι το γενικο σκεπτικο, δεν εχω γραψει καποιο κομμματι κωδικα ακομα για να γινω πιο κατατοπιστικος :P

[HdkiLLeR]

Ok κατανοητό,

1) σίγουρα δεν θα κάνεις δουλειά με το command line util. Θα πρέπει να χρησιμοποιήσεις το API προγραμματιστικά -- το πως θα το κάνεις το συζητάμε πιο μετά μιας και δεν το έχεις δει ακόμη οπότε comments σχετικά με τα arguments, IVs, seeds κλπ δεν έχουν νόημα τώρα.

2) γνώμη μου είναι να έχεις ένα code-base το οποίο είναι ανεξάρτητο του gui σου και μετά να φορέσεις το gui απο πάνω. Συνεπώς σε πρώτη φάση δες πως θα κάνεις utilize το socket framework, τι connection type θα χρησιμοποιήσεις (TCP/UDP), τι δομή θα έχουν τα messages που θα ανταλάζεις αλλά και πως τι features θα υποστηρίζεις (1-1 chat ή 1-N). Αυτά είναι βασικά να τα ξεκαθαρίσεις πριν κάνεις οτιδήποτε γιατί επηρεάζουν πολύ το πως θα περάσεις στο να προσθέσεις confidentiality properties*.

3) όλα αυτά που συζητάμε προυποθέτουν ότι τα parties σου θα έχουν keying material (δεδομένου ότι παίζεις με symmetric ciphers θα πρέπει να έχουν όλοι/γνωρίζουν το ίδιο key/passphrase). Οπότε υπάρχει και το θέμα πως τελικά όλοι θα γνωρίζουν αυτό το key, πως θα προκύπτει, κλπ κλπ (κοινώς θέλεις key establishment).

*: πχ εάν έχεις TCP streams τότε μπορείς εύκολα να χρησιμοποιήσεις aes-cbc, εάν έχεις UDP τότε πρέπει να χρησιμοποιήσεις κάποιο άλλο mode of operation γιατί τα properties του cbc προυποθέτουν reliable delivery.

[gkaueb]

Και το UDP μπορεί να γίνει reliable αν υλοποιήσεις έναν πολύ απλό hand shake μηχανισμό.

Δηλαδή αν o αποστολέας δεν λάβει επιβεβαίωση λήψης σε κάποιο χρονικό διάστημα αναμεταδίδει.


+ για instant messages έχω την εντύπωση ότι η εφαρμογή ενδείνυται να υλοποιείται πάνω από UDP

[WoLfeN Ilic]

2) γνώμη μου είναι να έχεις ένα code-base το οποίο είναι ανεξάρτητο του gui σου και μετά να φορέσεις το gui απο πάνω. Συνεπώς σε πρώτη φάση δες πως θα κάνεις utilize το socket framework, τι connection type θα χρησιμοποιήσεις (TCP/UDP), τι δομή θα έχουν τα messages που θα ανταλάζεις αλλά και πως τι features θα υποστηρίζεις (1-1 chat ή 1-N). Αυτά είναι βασικά να τα ξεκαθαρίσεις πριν κάνεις οτιδήποτε γιατί επηρεάζουν πολύ το πως θα περάσεις στο να προσθέσεις confidentiality properties*.

yeap αυτο σκοπευω να κανω. Ουσιαστικα το gui(δηλαδη οτι φτιαξω σε vbasic), ο μονος ρολος που θα εχει θα ειναινα κανει print και να δεχεται τα input του χρηστη. Ολα τα υπολοιπα θα στελνονται στο command line program, που αυτο θα κανει ουσιαστικα και ολη τη δουλεια.

3) όλα αυτά που συζητάμε προυποθέτουν ότι τα parties σου θα έχουν keying material (δεδομένου ότι παίζεις με symmetric ciphers θα πρέπει να έχουν όλοι/γνωρίζουν το ίδιο key/passphrase). Οπότε υπάρχει και το θέμα πως τελικά όλοι θα γνωρίζουν αυτό το key, πως θα προκύπτει, κλπ κλπ (κοινώς θέλεις key establishment).

now that's another problem. Περαν του εξωιντερνετικου τροπου επικοινωνιας και μοιρασματος του κλειδιου(δηλαδη προφορικα,γραπτα κλπ), δεν μπορω να σκεφτω καποιο τροπο.Ακομα και να γινεται το μοιρασμα κλειδιων με τη μορφη quiz(ερωτηση, σωστη απαντηση = κλειδι) με ενα man-in-the-middle attack καποιος μαθαινει τα παντα.

*: πχ εάν έχεις TCP streams τότε μπορείς εύκολα να χρησιμοποιήσεις aes-cbc, εάν έχεις UDP τότε πρέπει να χρησιμοποιήσεις κάποιο άλλο mode of operation γιατί τα properties του cbc προυποθέτουν reliable delivery.

για tcp σκεφτομουν..

[HdkiLLeR]

Και το UDP μπορεί να γίνει reliable αν υλοποιήσεις έναν πολύ απλό hand shake μηχανισμό.

Δηλαδή αν o αποστολέας δεν λάβει επιβεβαίωση λήψης σε κάποιο χρονικό διάστημα αναμεταδίδει.


+ για instant messages έχω την εντύπωση ότι η εφαρμογή ενδείνυται να υλοποιείται πάνω από UDP

Και έκανες το spoofing acceptable by design, επίσης πως διαφοροποιείς ένα retransmission (legitimate) απο ένα injected packet ή ένα replay;

Πέρα απο τα παραπάνω -- σε καθαρά protocol design επίπεδο -- πάλι έχεις prob, τι γίνεται εάν χαθεί το ack (το message έγεινε accept, δώθηκε στην εφαρμογή και στέλνεις ack); Ξαναστέλεις; Τότε η άλλη πλευρά θα πάρει παραπάνω απο μια φορές το ίδιο message γιατί δεν μπορεί να κάνει differentiate (retransmission vs same message again).

Το protocol design δεν είναι υπόθεση λεπτών..πόσο πραπάνω όταν θέλεις να είναι και σοβαρό (security minded) .

now that's another problem. Περαν του εξωιντερνετικου τροπου επικοινωνιας και μοιρασματος του κλειδιου(δηλαδη προφορικα,γραπτα κλπ), δεν μπορω να σκεφτω καποιο τροπο.Ακομα και να γινεται το μοιρασμα κλειδιων με τη μορφη quiz(ερωτηση, σωστη απαντηση = κλειδι) με ενα man-in-the-middle attack καποιος μαθαινει τα παντα.

Απο την στιγμή που έχεις το ιδιο key τότε έχεις όλα τα προβλήματα των passwords (reusable, collisions στον blockcipher, guessable, non-random, και πολλά άλλα). Σχετικά με το ΜΙΤΜ δεν ισχύει αυτό που λες. Υπάρχουν πολλοί τροποι να κάνεις secure key exchange πάνω απο insecure channels ακόμη και στην περίπτωση που υποθέτεις ότι κάποιος μπορεί να κάνει mitm, sniff, inject, etc (ότι έχει full control δηλαδή). Το IPSec παίζει πάνω απο το Inet οπότε το κάνει , ομοίως το SSL/TLS αλλά και δικά σου trivial key exchange protocols που μπορείς να ορίσεις με mixes απο public key crypto και symmetric ciphers (πχ signed diffie-helman key exchange).

για tcp σκεφτομουν..

Again it depends, πες μου όταν έρθει η ώρα όλο το model σου και θα σου πω. Hint: πως θα κάνεις differentiate τα messages; Το TCP είναι ένα full stream, δεν καταλαβαίνει πότε πρέπει να στείλει κάτι στην άλλη πλευρά, δεν διαφοποιεί γραμμές του chat. Εσύ κάνεις write()/send()/sendmsg() σε ένα socket αλλά αυτό δεν σημαίνει ότι αυτή την στιγμή ότι γράφτηκε θα "φύγει". Το TCP (συγκεκριμένα το stack του OS) κάνει buffer και αναλόγως με το πότε είναι ready (αλλά και τα options του που έχουν γίνει negotiate στην αρχή του session) στέλει ή όχι. Οπότε αυτό που κάνουν ολα τα messengers είναι ένα flash() μετά απο κάθε γραμή (readline() --> write() --> flush()). Απο την άλλη μεριά, φαντάσου ότι υπάρχει το ίδιο πράγμα πάλι (readline() --> write() -- >flush(()). Εάν έχεις κάνει encrypt τότε το \n (χαρακτήρας αλλαγής γραμής) πήγε υπερπίστεως (απο το mangle του encryption). Οπότε δεν θα διαβάζεις τπτ απο την άλλη πλευρά ή θα διαβάζεις μέχρι να γεμίσει ο buffer της readline (έχει και αυτή ένα max buff) και να σκάσουν τα πάντα .

[gkaueb]

Και έκανες το spoofing acceptable by design, επίσης πως διαφοροποιείς ένα retransmission (legitimate) απο ένα injected packet ή ένα replay;

Επίσης πέρα απο τα παραπάνω -- σε καθαρά protocol design επίπεδο -- πάλι έχεις prob, τι γίνεται εάν χαθεί το ack (το message έγεινε accept, δώθηκε στην εφαρμογή και στέλνεις ack); Ξαναστέλεις; Τότε η άλλη πλευρά θα πάρει παραπάνω απο μια φορές το ίδιο message γιατί δεν μπορεί να κάνει differentiate (retransmission vs same message again).

Σε αυτό το πρόβλημα υπάρχει η πανάρχαια ( ) τεχνική του counter. Δηλαδή αριθμείς κάθε πακέτο σου. Έτσι όταν ο παραλήπτης δεχτεί ένα πακέτο
με κωδικό - counter π.χ 2 το επεξεργάζεται και αναμένει πακέτο με αριθμό 3 για επόμενη επεξεργασία. Αν δεχτεί πάλι πακέτο με αριθμό 2 (περίπτωση retransmission) το κάνει reject και κάνει retransmit το ACK που θεωρητικά χάθηκε (κωδικός counter 2 ). Λύση η οποία φαίνεται πρόχειρη, σίγουρα με πολλά προβλήματα ασφάλειας, αλλά χρησιμοποιείται.

[WoLfeN Ilic]

Οπότε αυτό που κάνουν ολα τα messengers είναι ένα flash() μετά απο κάθε γραμή (readline() --> write() --> flush()). Απο την άλλη μεριά, φαντάσου ότι υπάρχει το ίδιο πράγμα πάλι (readline() --> write() -- >flush(()). Εάν έχεις κάνει encrypt τότε το \n (χαρακτήρας αλλαγής γραμής) πήγε υπερπίστεως (απο το mangle του encryption). Οπότε δεν θα διαβάζεις τπτ απο την άλλη πλευρά ή θα διαβάζεις μέχρι να γεμίσει ο buffer της readline (έχει και αυτή ένα max buff) και να σκάσουν τα πάντα .

μπορω αφου παρω το encrypted string να του χωσω ενα \n ετσι ωστε να το βλεπει
right?

[HdkiLLeR]

Σε αυτό το πρόβλημα υπάρχει η πανάρχαια ( ) τεχνική του counter. Δηλαδή αριθμείς κάθε πακέτο σου. Έτσι όταν ο παραλήπτης δεχτεί ένα πακέτο
με κωδικό - counter π.χ 2 το επεξεργάζεται και αναμένει πακέτο με αριθμό 3 για επόμενη επεξεργασία. Αν δεχτεί πάλι πακέτο με αριθμό 2 (περίπτωση retransmission) το κάνει reject και κάνει retransmit το ACK που θεωρητικά χάθηκε (κωδικός counter 2 ). Λύση η οποία φαίνεται πρόχειρη, σίγουρα με πολλά προβλήματα ασφάλειας, αλλά χρησιμοποιείται.

(δεν το είπες όλο αυτό πριν ) -- btw πάλι θέλεις κάποιο packet-level auth / message authentication code / message integrity code (πες το όπως θές) γιατί δεν μπορείς να ξέρεις ότι το το 2 είναι απο το messaging party σου και όχι ένα injected packet. Αυτού του τύπου τα protocols, τα οποία είναι stop & go (αλλά και τα variants αυτών που δουλεύουν με κάποιο window -- για performance μπορείς αντί να κάνεις send το επόμενο αφού έχεις πάρει το ack για το προηγούμενο packet/message, να στέλνεις ένα burst απο unacknowledged packets και να σταματήσεις. Όσο έρχονται acks συνεχίζεις με νέα messages, αρκεί πάντα τα not acknowledged packets σου να είναι N: window size) έχουν αυτό το prob ότι έαν υπάρξει ένα successful packet injection τότε τα δύο άκρα είναι out of sync. Οπότε με απλό counting δεν είναι και ιδιαίτερα δύσκολο να κάνω ακόμη και blind injection (να μην κάνω sniff) μιας και τα sequence numbers είναι predictable!

Οπότε αυτό που κάνουν ολα τα messengers είναι ένα flash() μετά απο κάθε γραμή (readline() --> write() --> flush()). Απο την άλλη μεριά, φαντάσου ότι υπάρχει το ίδιο πράγμα πάλι (readline() --> write() -- >flush(()). Εάν έχεις κάνει encrypt τότε το \n (χαρακτήρας αλλαγής γραμής) πήγε υπερπίστεως (απο το mangle του encryption). Οπότε δεν θα διαβάζεις τπτ απο την άλλη πλευρά ή θα διαβάζεις μέχρι να γεμίσει ο buffer της readline (έχει και αυτή ένα max buff) και να σκάσουν τα πάντα .

μπορω αφου παρω το encrypted string να του χωσω ενα \n ετσι ωστε να το βλεπει
right?

Μπορείς αλλά υπάρχει και περίπτωση να δημιουργηθούν additional \n απο το encryption (πχ το a --> \n αναλόγως το passphrase, iv και encryption mode) τα οποία θα σου χαλάσουν αυτό που θέλεις. Επίσης έχε υπόψην σου ότι μιλάμε τόση ώρα μόνο για encryption και key exchange. Εξίσου σημαντικό είναι και το integrity (για τους λόγους που αναφέρω παραπάνω), αλλά και για να μην μπορεί κάποιος να αλλάζει parts του μυνήματος σου. Με το να είναι encrypted δεν σημαίνει ότι εάν εγώ κάνω αλλαγές πάνω στο ciphertext αυτό θα το καταλάβει η άλλη πλευρά. Απλά όταν κάνει decrypt μπορεί να πάρει junk σαν output. Λέω μπορεί γιατι σε διάφορα modes μπορείς να έχεις predictable results στο output κάνοντας αλλαγές κατευθείαν στο ciphertext. Οπότε χωρίς integrity protection πάλι μπορώ να κάνω replace το \n και να σου κάνω concat messages, overlap, να γεμίζω buffers ώστε να κάνω drop (όλα αυτά αφαιρώντας το \n ).

[WoLfeN Ilic]

Μπορείς αλλά υπάρχει και περίπτωση να δημιουργηθούν additional \n απο το encryption (πχ το a --> \n αναλόγως το passphrase, iv και encryption mode) τα οποία θα σου χαλάσουν αυτό που θέλεις.

αυτο καπως λυνεται με 1-2 checks δε νομιζω πως ειναι τοσο δυσκολο να λυθει.Μπορω π.χ να κανω check αν υπαρχει στο string ο \n πριν απο το τελος και αν υπαρχει να το χωριζω σε chunks το μηνυμα και μετα να τα ενωνει η αλλη πλευρα

Επίσης έχε υπόψην σου ότι μιλάμε τόση ώρα μόνο για encryption και key exchange. Εξίσου σημαντικό είναι και το integrity (για τους λόγους που αναφέρω παραπάνω), αλλά και για να μην μπορεί κάποιος να αλλάζει parts του μυνήματος σου. Με το να είναι encrypted δεν σημαίνει ότι εάν εγώ κάνω αλλαγές πάνω στο ciphertext αυτό θα το καταλάβει η άλλη πλευρά. Απλά όταν κάνει decrypt μπορεί να πάρει junk σαν output. Λέω μπορεί γιατι σε διάφορα modes μπορείς να έχεις predictable results στο output κάνοντας αλλαγές κατευθείαν στο ciphertext. Οπότε χωρίς integrity protection πάλι μπορώ να κάνω replace το \n και να σου κάνω concat messages, overlap, να γεμίζω buffers ώστε να κάνω drop (όλα αυτά αφαιρώντας το \n ).

Το integrity δεν μπορει να λυθει με ssl/tls ή καποιο αλλο protocol?
Θα προτεινες καλυτερα assymetric cryptography?Και εκει υπαρχει το ιδιο προβλημα με το integrity..
Και εκει παλι θα εχω το ιδιο προβλημα με το μοιρασμα κλειδιων οπου ειναι απαραιτητο το confidentiality
Βασικα αν εξαιρεσουμε την πιθανοτητα ανταλλαγης κλειδιου/ων μεσω προσωπικης επαφης, το προβλημα του μοιρασματος εχει κοινα στοιχεια με το προβλημα του integrity μεταφορας του ciphertext

[HdkiLLeR]

Στην περίπτωση την δική σου το καλύτερο είναι να πάρεις το socket και να βάλεις απο πάνω του SSL/TLS (OpenSSL ή GnuTLS). Mπορείς να το ρυθμίσεις να κάνει mutual authentication και θα σου παρέχει confidentiality + integrity. Επίσης ορίζει δυναμικά κλειδιά και δεν έχεις προβλήματα με passwords, same keys, etc. Τέλος το SSL κάνει handle με τα δικά του records τα προβλήματα που λέμε παραπάνω οπότε εσύ πάλι γράφεις σε ένα stream αυτό που πρέπει να γράψεις και δεν χρειάζεται να ανυσηχείς για τπτ (αλλαγές γραμών κλπ).

Εαν πάλι θέλεις να το κάνεις με το χέρι τότε ουσιαστικά θέλεις είτε digital signatures / message (ώστε να γίνεται verification του message integrity) ή MAC/MIC -- και τα δυο το ίδιο πράγμα προσφέρουν, το πρώτο με asymmetric crypto και το δεύτερο με symmetric (θα πρότεινα MACs λόγο performance).

[WoLfeN Ilic]

Δεν εχεις αδικο, απλα δεν ξερω για ποσο ακομα θα ειναι ασφαλες το tls
οποτε αν οντως καταληξω προς τα εκει μαλλον μονο σε vbasic θα το κανω και αργοτερα ισως κοιταξω και για υλοποιηση σε *nix
θελω να ριξω πρωτα μια ματια σε αυτο http://venus.cslab.aueb.gr/forum/viewto ... f=8&t=7265

[HdkiLLeR]

Δεν εχεις αδικο, απλα δεν ξερω για ποσο ακομα θα ειναι ασφαλες το tls
οποτε αν οντως καταληξω προς τα εκει μαλλον μονο σε vbasic θα το κανω και αργοτερα ισως κοιταξω και για υλοποιηση σε *nix
θελω να ριξω πρωτα μια ματια σε αυτο http://venus.cslab.aueb.gr/forum/viewto ... f=8&t=7265

Τι εννοείς πόσο ακόμη ασφαλές θα έιναι το TLS? Τo TLSv1 είναι ουσιαστικά το SSLv3. Είναι IETF standard και είναι αρκετά extensible ώστε να καλύπτει νέα ciphers κλπ. Οι διαδικασίες για authentication (mutual or not), key exchange, rekeying, etc είναι όλες μελετημένες πάνω απο 10 χρόνια (~95 όταν η Νetscape μεσουρανούσε) και σε επίπεδο διαδικασιών είναι safe. Το security είναι θέμα implementation οπότε κάτι που είναι τόσο χρησιμοποιημένο και έχει περάσει τόσα source code reviews δεν νομίζω ότι θα είναι χειρότερο απο κάτι που θα γράψεις εσύ (no offense). Eπίσης ο AES η NSA τον προτείνει για secret και top-secret rated traffic.

Σε γενικές γραμμές είναι ένα protocol που έχει λάβει by-design υπόψην του το πως θα δημιουργείς random/one time keys για ένα και μόνο session (οπότε έχεις forward secrecy), πότε και πως θα γίνεται rekeying και πως θα κάνεις auth χρησιμοποιόντας ένα συνδιασμό απο public key crypto, diffie hellman key exchange, και symmetric crypto. Προσωπικά δεν νόμίζω ότι μπορείς να βρεις κάτι που να σου δίνει καλύτερο assurance γι' αυτό που θέλεις να κάνεις -- υποθέτοντας πάντα ότι θα το κάνεις σωστά integrate, κάτι που όπως στην πράξη δεν γίνεται ποτέ γι΄αυτό και υπάρχουν όλα αυτά τα breaches παρά την χρήση strong crypto.