Translated half of the file

www.i2p2/pages/how_intro_el.html

@@ -0,0 +1,175 @@
+{% extends "_layout_el.html" %}
+{% block title %}Μια μικρη εισαγωγη{% endblock %}
+{% block content %}
+
+<h2>Μια Μικρή Εισαγωγή στο Πως Δουλεύει το I2P</h2>
+
+<p>
+Το I2P είναι ένα πρόγραμμα για τη δημιουργία, την ανάπτυξη και τη διατήρηση ενός δικτύου
+που υποστηρίζει ασφαλή και ανώνυμη επικοινωνία. Τα άτομα που χρησιμοποιούν το I2P μπορούν
+να ελέγξουν το ποσοστό μεταξύ της ανωνυμίας, της αξιοπιστίας, της χρησιμοποίησης του
+bandwidth και της καθυστέρησης. Δεν υπάρχει κάποιο κεντρικό σημείο στο δίκτυο στο οποίο
+μπορεί να ασκηθεί πίεση ώστε να διακινδυνέψει η ακεραιότητα, η ασφάλεια ή η ανωνυμία του
+συστήματος. Το δίκτυο υποστηρίζει δυναμική αναδιαμόρφωση ως απάντηση σε διάφορες επιθέσεις
+και έχει σχεδιαστεί ώστε να χρησιμοποιεί επιπλέον πόρους όταν αυτοί γίνονται διαθέσιμοι.
+Φυσικά, όλες οι πτυχές του δικτύου είναι ανοιχτές και ελεύθερα διαθέσιμες.
+</p>
+
+<p>
+Εν αντιθέσει με άλλα ανώνυμα δίκτυα, το I2P δεν προσπαθεί να παρέχει ανωνυμία κρύβοντας τον
+αποστολέα ενός μηνύματος αλλά όχι τον παραλήπτη, και αντίστροφα. Το I2P έχει σχεδιαστεί ώστε
+να επιτρέπει σε κόμβους που χρησιμοποιούν το I2P να επικοινωνούν μεταξύ τους ανώνυμα &mdash;
+και ο αποστολέας και ο παραλήπτης είναι μη αναγνωρίσιμοι μεταξύ τους αλλά και σε τρίτους.
+Για παράδειγμα, σήμερα υπάρχουν και ιστοσελίδες μέσα στο I2P (επιτρέποντας ανώνυμη δημοσίευση
+ / φιλοξενία) καθώς και HTTP proxies για το κανονικό Internet (επιτρέποντας ανώνυμη περιήγηση
+στο διαδίκτυο). Η δυνατότητα να τρέχετε εξυπηρετητές μέσα στο I2P είναι απαραίτητη, καθώς είναι
+πολύ πιθανό κάποια outbound proxies για το κανονικό Internet να παρακολουθούνται, να είναι
+απενεργοποιημένα ή να έχουν παραβιαστεί με σκοπό κάποια επίθεση.
+</p>
+
+<p>
+Το δίκτυο είναι "μηνυματοστραφές" - είναι ουσιαστικά ένα ασφαλές και ανώνυμο επίπεδο IP, όπου
+τα μηνύματα απευθύνονται σε κρυπτογραφικά κλειδιά (Προορισμοί) και μπορεί να είναι αρκετά
+μεγαλύτερα από τα IP πακέτα. Κάποια παραδείγματα χρήσης του δικτύου περιλαμβάνουν τα "eepsites"
+(εξυπηρετητές ιστού που φιλοξενούν κανονικές διαδικτυακές εφαρμογές μέσα στο I2P), μία
+εφαρμογή-πελάτη για το BitTorrent ("I2PSnark"), ή μία κατανεμημένη αποθήκη δεδομένων. Με τη
+βοήθεια της εφαρμογής <a href="i2ptunnel">I2PTunnel</a>, είμαστε ικανοί για μία παραδοσιακή
+TCP/IP επικοινωνία πάνω από το I2P, όπως το SSH, IRC, ένα squid proxy ακόμα και streaming ήχου.
+Οι περισσότεροι άνθρωποι δεν θα χρησιμοποιήσουν το I2P ευθέως, ή ακόμα δεν χρειάζεται να ξέρουν
+ότι το χρησιμοποιούν. Αντιθέτως αυτό που θα βλέπουν, θα είναι μία από τις I2P εφαρμογές, ή ίσως
+κάποια εφαρμογή διαχείρισης που θα τους επιτρέπει να ανοίξουν και να κλείσουν κάποιους proxies
+που τους παρέχουν ανωνυμία.
+</p>
+
+<p>
+Μία απαραίτητη διαδικασία του σχεδιασμού, της ανάπτυξης και της δοκιμής ενός ανώνυμου δικτύου είναι
+να οριστεί το <a href="how_threatmodel">threat model</a>, εφόσον δεν υπάρχει κάτι σαν "αληθινή"
+ανωνυμία, αλλά μόνο αυξανόμενα μεγάλο κόστος για την αναγνώριση κάποιου. Συνοπτικά, ο σκοπός του
+I2P είναι να επιτρέπει στους ανθρώπους να επικοινωνούνε σε διάφορα εχθρικά περιβάλλοντα προσφέροντας
+καλή ανωνυμία, με την βοήθεια επαρκούς "κίνησης κάλυψης" από την κίνηση διάφορων άλλων ανθρώπων που
+απαιτούν λιγότερη ανωνυμία. Με αυτό τον τρόπο, μερικοί χρήστες μπορούν να αποφύγουν την ανίχνευση
+από κάποιον πολύ ισχυρό εχθρό, ενώ άλλοι προσπαθούν να αποφύγουν κάποιον πιο αδύναμο, <i>όλα στο
+ίδιο δίκτυο</i>, όπου τα μηνύματα καθενός είναι ουσιαστικά δυσδιάκριτα από των αλλωνών.
+</p>
+
+<h2>Γιατί;</h2>
+<p>
+Υπάρχει μία πληθώρα από λόγους για τους οποίους θέλουμε ένα σύστημα να υποστηρίζει ανώνυμη
+επικοινωνία και ο κάθε ένας έχει τους δικούς του λόγους. Υπάρχουν διάφορες
+<a href="how_networkcomparisons">άλλες προσπάθειες</a> που προσπαθούν να παρέχουν διάφορους
+τρόπους ανωνυμίας στα άτομα σε όλο το Internet, αλλά δεν μπορούσαμε να βρούμε κάποιο που να
+ικανοποιούσε τις ανάγκες μας ή το threat model μας.
+</p>
+
+<h2>Πώς;</h2>
+
+<p>
+Το δίκτυο με μια ματιά αποτελείται από ένα πακέτο από κόμβους ("routers") με έναν αριθμό από
+μονής κατεύθυνσης inbound και outbound εικονικά μονοπάτια ("tunnels", όπως περιγράφονται στη
+σελίδα <a href="how_tunnelrouting">tunnel routing</a>). Κάθε router αναγνωρίζεται από μία
+κρυπτογραφική ταυτότητα (RouterIdentity) που συνήθως έχει μεγάλη διάρκεια ζωής. Αυτοί οι
+routers επικοινωνούν μεταξύ τους μέσω υπαρχόντων μηχανισμών μεταφοράς (TCP, UDP, κτλ),
+ανταλλάσσοντας διάφορα μηνύματα. Οι εφαρμογές πελάτη έχουν τα δικά τους κρυπτογραφικά
+αναγνωριστικά ("Destination") που τους επιτρέπουν να στέλνουν και να λαμβάνουν μηνύματα. Αυτές
+οι εφαρμογές-πελάτες μπορούν να συνδεθούν σε οποιοδήποτε router και να εξουσιοδοτηθούν για προσωρινή
+δέσμευση ("lease") μερικών tunnels που θα χρησιμοποιηθούν για την αποστολή και παραλαβή μηνυμάτων
+στο δίκτυο. Το I2P έχει τη δικιά του εσωτερική <a href="how_networkdatabase">δικτυακή βάση δεδομένων</a>
+(χρησιμοποιώντας μια παραλλαγή του αλγορίθμου Kademlia) για την ασφαλή κατανεμημένη δρομολόγηση και
+εύρεση στοιχείων επικοινωνίας.
+</p>
+
+<div class="box" style="text-align:center;"><img src="_static/images/net.png" alt="Network topology example" title="Παράδειγμα Τοπολογίας Δικτύου" /></div>
+
+
+<p>
+Παραπάνω, η Alice, o Βοb, ο Charlie και ο Dave τρέχουν routers με μοναδικό Προορισμό στο τοπικό τους
+router. Όλοι τους έχουν ένα ζευγάρι από 2-hop inbound tunnels για κάθε προορισμό (σημειώνονται ως 1,
+2, 3, 4, 5 και 6). Επίσης εμφανίζεται ένα μικρό μέρος από τα 2-hop outbound tunnels από τα router κάθε
+χρήστη. Χάριν απλότητας, τα inbound tunnels του Charlie και τα outbound tunnels του Dave δεν εμφανίζονται,
+ούτε τα διαθέσιμα outbound tunnels των υπολοίπων routers (συνήθως εφοδιασμένα με μερικά tunnels τη φορά).
+Όταν η Alice και ο Bob μιλάνε μεταξύ τους, η Alice στέλνει ένα μήνυμα από τα (ροζ) outbound tunnels της που
+επικοινωνούν με ένα από τα (πράσινα) inbound tunnels του Bob (tunnel 3 ή 4). Γνωρίζει σε ποιο από όλα τα tunnels
+του router να το στείλει ρωτώντας τη δικτυακή βάση δεδομένων, που είναι συνεχώς ενημερωμένη καθώς νέα
+leases εξουσιοδοτούνται και παλιά λήγουν.
+</p> 
+
+<p>
+Εάν ο Bob θέλει να απαντήσει στην Alice, ακολουθάει πάλι την ίδια διαδικασία - στέλνει ένα μήνυμα από ένα
+από τα outbound tunnels του που επικοινωνούν με ένα από τα inbound tunnels της Alice (tunnel 1 ή 2). Για
+να γίνουν πιο εύκολα τα πράγματα, τα περισσότερα μηνύματα μεταξύ της Alice και του Bob είναι
+<a href="how_garlicrouting">garlic</a> wrapped, έχοντας τις τωρινές lease πληροφορίες του αποστολέα έτσι
+ώστε ο αποδέκτης να μπορεί να απαντήσει αμέσως χωρίς να χρειάζεται να κοιτάξει στη δικτυακή βάση δεδομένων
+για τις τωρινές πληροφορίες.
+</p>
+
+<p>To deal with a wide range of attacks, I2P is fully distributed with no centralized resources - and 
+hence there are no directory servers keeping statistics regarding the performance and reliability of 
+routers within the network. As such, each router must keep and maintain profiles of various routers 
+and is responsible for selecting appropriate peers to meet the anonymity, performance, and reliability 
+needs of the users, as described in the <a href="how_peerselection">peer selection</a> page.</p>
+
+<p>The network itself makes use of a significant number of <a href="how_cryptography">cryptographic techniques and algorithms</a> - 
+a full laundry list includes 2048bit ElGamal encryption, 256bit AES in CBC mode with PKCS#5 padding, 
+1024bit DSA signatures, SHA256 hashes, 2048bit Diffie-Hellman negotiated connections with station to 
+station authentication, and <a href="how_elgamalaes">ElGamal / AES+SessionTag</a>.</p>
+
+<p>Content sent over I2P is encrypted through three layers garlic encryption (used to verify the delivery of the message to 
+the recipient), tunnel encryption (all messages passing through a tunnel is encrypted by the tunnel 
+gateway to the tunnel endpoint), and inter router transport layer encryption (e.g. the TCP transport 
+uses AES256 with ephemeral keys):</p>
+<p>End-to-end (I2CP) encryption (client application to server application) was disabled in I2P release 0.6; 
+end-to-end (garlic) encryption (I2P client router to I2P server router) from Alice's router "a" to Bob's router "h" remains.
+Notice the different use of terms! All data from a to h is end-to-end encrypted, but the I2CP connection
+between the I2P router and the applications is not end-to-end encrypted!
+A and h are the routers of Alice and Bob, while Alice and Bob in following chart are the applications running atop of I2P.</p>
+
+<div class="box" style="text-align:center;"><img src="_static/images/endToEndEncryption.png" alt="End to end layered encryption" title="End to end layered encryption." /></div>
+
+<p>The specific use of these algorithms are outlined <a href="how_cryptography">elsewhere</a>.</p>
+
+<p>The two main mechanisms for allowing people who need strong anonymity to use the network are 
+explicitly delayed garlic routed messages and more comprehensive tunnels to include support for pooling 
+and mixing messages. These are currently planned for release 3.0, but garlic routed messages with no 
+delays and FIFO tunnels are currently in place. Additionally, the 2.0 release will allow people to set 
+up and operate behind restricted routes (perhaps with trusted peers), as well as the deployment of more 
+flexible and anonymous transports.</p>
+
+<p>Some questions have been raised with regards to the scalability of I2P, and reasonably so. There 
+will certainly be more analysis over time, but peer lookup and integration should be bounded by 
+<code>O(log(N))</code> due to the <a href="how_networkdatabase">network database</a>'s algorithm, while end to end 
+messages should be <code>O(1)</code> (scale free), since messages go out K hops through the outbound 
+tunnel and another K hops through the inbound tunnel, with K no longer than 3.
+The size of the network (N) bears no impact.</p>
+
+<h2>When?</h2>
+<p>I2P initially began in Feb 2003 as a proposed modification to 
+<a href="http://freenetproject.org">Freenet</a> to allow it to use alternate transports, such as 
+<a href="http://java.sun.com/products/jms/index.jsp">JMS</a>, then grew into its own as an 
+'anonCommFramework' in April 2003, turning into I2P in July, with code being written in earnest starting in August '03.
+I2P is currently under development, following
+the <a href="roadmap">roadmap</a>.</p>
+
+<h2>Who?</h2>
+<p>We have a small <a href="team">team</a> spread around several continents, working to advance different 
+aspects of the project.  We are very open to other developers who want to get involved and anyone else 
+who would like to contribute in other ways, such as critiques, peer review, testing, writing I2P enabled 
+applications, or documentation. The entire system is open source - the router and most of the SDK are 
+outright public domain with some BSD and Cryptix licensed code, while some applications like I2PTunnel 
+and I2PSnark are GPL. Almost everything is written in Java (1.5+), though some third party applications 
+are being written in Python and other languages. The code works on <a href="http://java.com/en/">Sun Java SE</a> and other Java Virtual Machines.
+</p>
+
+<h2>Where?</h2>
+<p>Anyone interested should
+join us on the IRC channel #i2p (hosted concurrently on irc.freenode.net, irc.postman.i2p, irc.freshcoffee.i2p, irc.welterde.i2p and irc.einirc.de).
+There are currently no scheduled development meetings, however
+<a href="meetings">archives are available</a>.</p>
+
+<p>The current source is available in <a href="monotone.html">monotone</a>.</p>
+
+<h2>Additional Information</h2>
+<p>
+See <a href="how.html">the Index to Technical Documentation</a>
+</p>
+
+{% endblock %}