Entropy_RSA 0.9.1: kein Erfolg auf Nicht-i386-Architektur
[ Entropy Forum ]
Geschrieben von / Written by Stef am 07. Oktober 2007 22:12:40:
Gibt es jemanden, der ein lauffähiges Entropy_RSA-Binary für eine Nicht-i386-Architektur compilieren konnte? Ich habe das Gefühl, dass JEDE GCC-Version auf Nicht-i386-Architekturen Entropy_RSA-Binaries erzeugt, die ungültige McEliece-Schlüssel erzeugen!
Zuerst habe ich es auf der MIPS-Architektur versucht, um Entropy auf Freifunk-Geräten mit USB-Schnittstelle (z.B. ASUS WL500G oder ASUS WL500G Premium) betreiben zu können. (freie Informationen in einem freien Netzwerk!)
Mittels Toolchain von OpenWRT habe ich mittels Crosscompiler und native-Compiler zwar ein Binary compilieren können, jedoch können die Entropy-Knoten keine P2P-Verbindungen aufbauen (siehe http://f27.parsimony.net/forum66166/messages/7212.htm).
Symptome: Jeder kontaktierte Knoten hat 32 eingehende Verbindungen im Status "Connected", jedoch werden nur 881Bytes übertragen und die Verbindungen bleiben hängen. Ausgehende Verbindungen kommen überhaupt nicht zu Stande, offenbar ein Problem mit dem Austausch der Public Keys.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Meine neueste "Serverplattform" ist die NSLU2 ( http://de.wikipedia.org/wiki/NSLU2 ), hat 32MB RAM, 8MB Flash, 266MHz CPU und es wird von Debian unterstützt! (einfache Installation von DebianSlug: siehe http://www.cyrius.com/debian/nslu2/unpack.html ).
Auf der NSLU2 unter DebianSlug habe ich Entropy_RSA mit gcc-4.1, gcc-3.3 und gcc-3.4 compiliert und auf den vier NSLU2-Geräten getestet. Ich hatte jeweils den Store gelöscht und somit bei jedem Testlauf das Entropy-Testnetz von Null an gestartet. Mit keinem Binary kamen Verbindungen zu Stande, entweder die gleichen Symptome wie oben beschrieben, oder z.B. mit gcc-3.4 folgende Symptome:
Keine ausgehenden Verbindungen, jedoch 32 eingehende Verbindungen auf jedem Knoten. Diesmal Null Byte übertragene Daten, der Status der Verbindungen wird als "read error" oder "end of file" angezeigt.Auswertung des loganalyzer.sh-Scriptes:
==> Running the Entropy Log Analyzer...
==> Analysis Complete.The logfile shows 1 unique Entropy startup(s) and 0 'New Day' notices.
Normal: Found 43 node maintenance execution(s).
Warning: Found 10 McEliece public key failure(s). Aren't you glad we checked? :-)
Warning: Found 21 failed outbound connection setup(s).===> End Report.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Nun denn, vorläufig stelle ich weitere Versuche ein und bleibe bei Entropy-0.8.3. Es läuft zwar ziemlich langsam auf der NSLU2, dafür verheizt so ein Entropy-Knoten nur max 10W. Es wäre cool, wenn im städteweiten Freifunk-Netzwerk so gegen 100 Entropy-Knoten laufen würden. :-)
Eine andere Lösung wäre GNUnet, dies ist bei Debian enthalten und kann mittels "apt-get install gnunet-server" installiert werden. Ich kenne mich zwar mit GNUnet nicht aus, es wirkt aber ziemlich abschreckend für "nicht-Geeks"... :-(
Freenet0.7 wäre cool, da es aktiv weiterentwickelt wird und coole Features hat. Leider war der GIJ-Test gemäss http://wiki.freenetproject.org/Freenet0Point7withFreeVm nicht erfolgreich, irgendwie läuft Java auf DebianSlug überhaupt nicht.
MagmaFS muss ich mal ausprobieren, leider ist es nicht anonym und leider benötigt es mehrere Softwarekomponenten für den Betrieb des Systems. Die einfache Integration von Windowsrechnern wäre ziemlich mühsam.
Es gibt viele interessante Projekte zur verteilten Datenspeicherung, jedoch habe ich das perfekte Programm für leistungsschwache "Server"-Hardware noch nicht gefunden:
-dezentraler Aufbau als städteweites Mesh
-headless (nur SSH-Terminal)
-lauffähig unter Linux
-benutzerfreundlich
-einfache Administration
-redundante und ausfallsichere Datenspeicherung
-aktives Entwicklungsprojekt
-Anonymität (Abstreitbarkeit), um keine rechtlichen Probleme zu bekommen
Hat jemand einen Tipp?MfG,
Stef.
[ Entropy Forum ]