XR232 - Echter Zufall und echtes RS232-Protokoll

Stromversorgung

Der TRNG wird aus einem konventionellen Netztrafo mit 9VAC Sekundärspannung und mindestens 100mA Belastbarkeit versorgt. Bestens geeignet sind die üblichen Steckernetzteile für analoge Modems und Anrufbeantworter (9V / 500-1000mA), weil solche Trafos gewöhnlich in kapazitätsarmer Zweikammerbauweise ausgelegt sind, sodass die kapazitive Kopplung ins Stromnetz nicht allzu stark ist. Auch ein konventionelles 12V-Gleichspannungsnetzteil kann verwendet werden. (Bitte kein Schaltnetzteil!)

Die Wechselspannung wird über eine diskret aufgebaute Graetz-Brücke, bestehend aus D1-D4 (1N4001) mit parallel geschalteten HF-Abblockkondensatoren C1-C4 (47nF) gleichgerichtet und im ersten Siebelko C5 (1000µF/25V) geglättet.
An dieser Stelle sollten bei Verwendung eines 9VAC-Netzteils etwa 12VDC (entsprechend der Sinus-Spitzenspannung), bei Verwendung eines 12VAC-Netzteils etwa 16VDC anstehen. C5 ist somit ein erster wichtiger Messpunkt, falls sich garnichts tut und auch die LED nicht leuchtet.

Die gesiebte Gleichspannung gelangt auf einen konventionellen Festspannungsregler VR1 (7805), der den Digitalteil mit stabilen 5V versorgt. An dieser Stelle kommt selbstverständlich kein Schaltregler infrage, sondern nur ein Linearregler, der von sich aus keine hochfrequenten Störungen verursacht! Daher bitte auch den Abblockkondensator C7 nicht vergessen, dieser verhindert eine Selbsterregung des Spannungsreglers.
Der Strombedarf des Digitalteils beträgt nur maximal 60 mA. Zwischen 12...16V Eingangsgleichspannung. Die Verlustleistung von maximal 0,3 Watt kann der Linearregler noch ohne zusätzlichen Kühlkörper abgeben. Wer sich damit unwohl fühlt oder ein Netzteil mit höherer Gleichspannung anschließen will, der kann ja ein Kühlblech anschrauben. (Schaden kann es jedenfalls nicht.)

An die Betriebsspannung der Rauschquelle sind andere Forderungen zu stellen. Die Rauschquelle stabilisiert sich in weitem Betriebsspannungsbereich von selbst, ihre Betriebsspannung muss also keineswegs auf einen Festwert stabilisiert sein. Sie sollte aber besonders sauber und frei von Lastschwankungen des Digitalteils sein. Und natürlich muss die Betriebsspannung für die Rauschquelle mindestens 1V über der Nennspannung der verwendeten Z-Diode liegen, damit der Rauscheffekt genutzt werden kann. Da die Rauschquelle nur etwa 1mA Betriebsstrom benötigt, reicht ein klassisches RC-Siebglied, bestehend aus R2 (2k2) und C6 (1000µF) vollkommen aus, um aus der eventuell noch leicht verbrummten Rohspannung an C5 eine hochreine Gleichspannung in Batteriequalität zu machen.

Radikale Idee - Batterie statt Netzteil?
Alles in einen Metallkasten verfrachten und diesen noch besser von der Außenwelt abschirmen, zum Beispiel mit Bleiplatten gegen die Röntgen- und Gamma-Hintergrundstrahlung? Kann man machen...
Meiner Meinung nach spricht erst einmal nichts dagegen, außer vielleicht der Strombedarf der LSTTL-Bausteine. Inzwischen hat sich leider heraus kristallisiert, dass 74HC-Bausteine in dieser Anwendung doch keine vollwertige Alternative zu LSTTL-Bausteinen sind. Man müsste also schon einen kleinen Bleiakku oder eine etwas größere Lithiumbatterie verwenden.
Und immer schön den Ladezustand im Auge behalten! Ich selbst habe mal mit einem 12V-Pack aus Alkali-Batterien experimentiert. Wichtigste Erkenntnis: Wenn man vergisst, das Gerät bei Nichtbenutzung auszuschalten, dann kann es vorkommen, dass man Stunden später immernoch Daten geliefert bekommt, die aber nur noch aus den Werten $00 oder $FF bestehen. Was war passiert - die Rauschquelle hatte ihren Dienst versagt, weil die Batteriespannung bereits die Zenerspannung unterschritten hatte, aber es war noch genügend Saft für den Logikteil, dessen Betriebsspannung ja zusätzlich stabilisiert ist.
Mein Vorschlag für einen Akkubetrieb inklusive ultrasimpler Ladeschaltung, ohne Layout-Änderungen:
Der Pfad vom Pluspol der Gleichrichterbrücke zu C5 und VR1 ist aufzutrennen und an dieser Stelle ein einpoliger Umschalter einzusetzen. Der Pluspol des Akku-Packs wird über diesen Umschalter entweder auf den Pluspol des Gleichrichters oder auf C5/VR1 geschaltet. (Minuspol mit GND verbunden). In den Wechselstrompfad X1 sollte noch ein für den gewünschten Ladestrom dimensionierter Vorwiderstand eingebaut werden. Man könnte dann mit einem Wechsel- oder Gleichspannungsnetzteil den Akku laden, ODER den XR232 mit absolut reinem Gleichstrom betreiben.

Rauschquelle

Die gegenwärtige Version der Rauschquelle (im Schaltbild mit "X" bezeichnete Komponenten) beruht auf einer Kleinleistungs-Z-Diode 9V1 (z.B. Standardtyp C9V1, Philips) und zwei bipolaren NPN-Transistoren (Standardtyp BC547C).
Die "Rauschdiode" XZD liegt gleichstrommäßig im Gegenkopplungszweig der konventionellen Emitterschaltung aus XVT1/XR1/XR2. Bei ausreichend hoher Betriebsspannung stabilisieren sich die Arbeitspunkte von Transistor und Diode automatisch im Bereich der Z-Spannung (genau genommen im Kennlinienknick derselben plus Spannungsabfall an der B-E-Strecke des Transistors). Dadurch stellt sich immer der optimale Arbeitspunkt für den "Rauschbetrieb" ein und die Schaltung wird vollkommen abgleichfrei. Nebenbei wird sie in gewissem Umfang gegen Spannungsschwankungen und Temperaturdrift unempfindlich.
Die Kathode von XZD liegt über XC1 wechselstrommäßig direkt auf Schaltungsmasse / Emitterpotenzial von XVT1.
Das dem Diodenstrom überlagerte Rauschen gelangt praktisch ungedämpft auf die Basis von XVT1 und wird von diesem, noch annähernd linear, um etwa den Faktor 250 verstärkt. Am Kollektor steht bereits ein Nutzsignal in der Größenordnung von 1V_SS.
Über XC2 wird der Wechselstromanteil dieses Signals augekoppelt und auf die zweite Stufe mit XVT2/XR3 gegeben. Sie hebt das Signal bis in die Begrenzung an. Das Ergebnis entspricht dem, was man mit einer Komparatorschaltung erzielt hätte (nur störsicherer): Der Kollektor von XVT2 liefert (über den externen Pullup-Widerstand R3) ein digitales Rauschen mit gut lesbaren TTL-Pegeln.

Balancierung

Das digitalisierte Rauschen geht auf den Takteingang des als Frequenzteiler arbeitenden ersten Flipflops von IC3a (74LS74, Pin 3).
Als digitales Balancierungsverfahren ist die Frequenzzeilung in ihrer Effizienz vergleichbar mit der XOR- oder Von-Neumann-Verknüpfung aufeinander folgender Bits: Am Ausgang steht ein nahezu perfekt ausgeglichenes digitales Zufalls-Rauschen. Auch hierbei geht die Hälfte der ursprünglichen Bandbreite verloren, was wir uns in diesem Fall aber durchaus leisten können.
Aus dem balancierten aber nach wie vor asynchronen Roh-Datenstrom holt sich der angeschlossene Computer per digitalem Sample-and-Hold (D-Flipflop in IC3) seine Zufallsbits mit der jeweils benötigten seriellen Abtastrate.

Taktgewinnung

Zur Gewinnung des Sampling-Taktes und zur Steuerung der Logik für die Erzeugung von Start-/Stoppbits wird das vom Rechner kommende TxD-Signal (X2b) konsequent bipolar ausgewertet. So können die Flankenwechsel auch unter schwierigeren Bedingungen (lange Leitung, schwache Leitungstreiber) besonders sicher regeneriert werden. Voraussetzung ist natürlich, dass die Schnittstelle einigermaßen normgerechte und vor allem bipolare Spannungspegel liefert.
TxD steuert, je nach Polarität, entweder die Sende-LED in PC1 oder diejenige in PC2 durch. Die Phototransistoren auf TTL-Seite ziehen abwechselnd die Eingänge von zweien als R/S-Flipflop verschalteten NAND-Gatter in IC1c/d (74LS00) auf Massepotenzial. An den Ausgängen (Pins 8 und 11) dieser bistabilen Kippschaltung findet man ein sauber regeneriertes und flankensteiles TxD-Signal mit TTL-Pegeln.
Mit Hilfe eines Wired-AND (D5/D6, Pullup R5) werden beide Ausgänge des RS-FF kombiniert, um aus jedem Flankenwechsel einen kurzen positiven Impuls zu gewinnen. Sendet der Computer über TxD seine Taktzeichen (0-10101010-1), dann liefert die Auswertung der Flankenwechsel genau 10 Impulse im Zeitraster der aktuell verwendeten Baudrate. Damit hat der Zufallsgenerator alles, was er braucht, um eigene serielle Zeichen zu generieren.

Platinenherstellung

Der neue Platinenentwurf (Bild 5a) enthält nicht nur die zusätzlichen Bauteile, ich habe auch darauf geachtet, etwas mehr Kupfer stehen zu lassen. Nach wie vor dürfte das Bestücken der Platine auch für weniger geübte Lötkünstler kein Problem sein. Mit ihrem "Formfaktor" von mind. 50x100mm passt die Platine in diverse Standard-Gehäuse. "Zufällig" gibt es Photopositiv-Material genau in diesem Zuschnitt... Andere Variante: Gleich drei Platinenlayouts mit ein paar Millimetern Abstand auf eine Europaplatte von 160x100 mm belichten; die kann man dann auch als Grobmotoriker noch verlustfrei durchsägen...

Sowohl für den Toner-Transfer, wie auch für den Ausdruck auf Folie oder Transparentpapier (Photopositiv-Belichterfolie) muss der XR232-Schriftzug im Druck seitenverkehrt zu lesen sein, denn die bedruckte Seite soll wie üblich direkt auf dem Kupfer aufliegen.
Auf der Kupferfläche soll der Schriftzug also wieder seitenrichtig erscheinen, es sei denn, man hat Bock drauf, die ganze Platine seitenverkehrt zu bestücken und alle ICs auf links zu biegen... jetzt, wo ich's schreibe... hihi...

Bestückung

Siehe Layout/Bestückungsplan in Bild 5b! Zur Bestückung ist eigentlich nichts Besonderes zu sagen. Die vielleicht wichtigste Regel: Zuerst mit den Bauteilen anfangen, die man im weiteren Verlauf allzu leicht vergessen würde... Drahtbrücken und so. Es ist auch durchaus möglich, alle Bauteile erstmal durchzustecken und durch Umbiegen der Anschlussdrähte zu fixieren. Die Anschlüsse von hochwertigen IC-Fassungen sollte man nur sehr vorsichtig biegen, da sie relativ leicht abbrechen. Oder einfach mit etwas Kleber die Fassungen provisorisch auf der Platine fixieren. Sieht man ja später nicht. Nach einer nochmaligen Sichtprüfung kann man dann in einem Rutsch loslöten.
Für Optokoppler im DIL-6-Gehäuse gibt es zwar auch hübsche DIL-6-Fassungen, aber weil hier eine ganze Armada von Optokopplern nebeneinander liegt, bietet es sich an, einfach aus zwei SIL-Sockelleisten (Gesamtbreite 18 Pins) eine einzige Riesen-Fassung zu basteln. Diese Variante ist auch in Bild 1 zu erkennen.
Beim Einsetzen der ICs und Optokoppler bitte darauf achten: Die "Nasen" der Optokoppler PC1, PC2 und PC5 zeigen nach unten, die aller anderen ICs nach oben!

RS232-Anschluss

Ein XR232-Anschlusskabel darf mehrere Meter lang sein. Gut geeignet sind ganz normale Telefonschnüre (aber nur die mit lötbaren Adern, nicht dieser Faserkram...!). Es muss nicht zwangsläufig ein geschirmtes Kabel sein. Wenn doch, dann bitte das Geflecht nur auf PC-Seite mit dem Massekragen des Steckers verbinden!
Wenn Zufallsgenerator und PC-System hinreichend gut abgeschirmt sind (Metallgehäuse), muss der Zufallsgenerator keinen besonderen Sicherheitsabstand zum PC-System haben. Am besten macht man das Kabel nur so lang, wie es für den praktischen Einsatz erforderlich ist. (Notfalls gibt's noch  1-zu-1-Verlängerungskabel zum dazwischenschalten.)

Für den RS232-Stecker (genau genommen ist es die Buchse) gibt es zwei mögliche Anschlussbelegungen, von denen ich aber nur die Anschlussvariante 1 ausdrücklich empfehlen kann:

Anschlussvariante 1 Nebenstehend die favorisierte Anschlussbelegung für den 9-poligen SUB-D-Stecker. Diese Variante funktioniert mit den allermeisten Terminalprogrammen auf Anhieb, da sie am ehesten dem normgemäßen Verhalten der Schnittstelle entgegenkommt. Leitung "c" ist die Anzapfung der DTR-DSR-Brücke (Anschlüsse 4+6). Sie liefert dem XR232 einerseits eine positive Hilfsspannung für das Opto-Interface, andererseits wird der Pegel von DTR auch zum kontrollierten Setzen des Bitzählers genutzt (siehe Erläuterungen zur Funktion der Schaltung und zum Protokoll). Die Brücken zwischen Pin 7 und Pin 8 (RTS/CTS) sowie Pin 4 und Pin 6 (DTR/DSR) lötet man direkt an die 9-polige D-SUB-Buchse, dann muss das Verbindungskabel zum XR232 nur 4-adrig sein.

Anschlussvariante 2 Diese alternative Anschlussmöglichkeit verwendet für Leitung "c" die RTS-CTS-Brücke (Anschlüsse 7+8) zur Gewinnung einer positiven Hilfsspannung und zum Setzen des Bitzählers. Allerdings bringt Anschlussvariante 2 keinen technischen Vorteil im Vergleich zu Anschlussvariante 1. Die meisten Terminalprogramme können zwar RTS gezielt hochsetzen, sobald man die Kommunikation eröffnet (Option "RTS/CTS-Handshake" einschalten!), aber dieses Verhalten entspricht nicht unbedingt der ursprünglichen Schnittstellendefinition, nach der RTS-CTS zur Steuerung des laufenden Datenflusses nach dem Zustandekommen einer Verbindung (also nach dem korrekten Abfragen der DTR-DSR-Bedingung) gedacht war. Im Gegensatz dazu berücksichtigen viele Programmierumgebungen die Leitungen RTS-CTS zunächst einmal garnicht, es sei denn, man hat vorher entsprechende Schalter konfiguriert. So gesehen erscheint Anschlussvariante 1 ganz allgemein "logischer".

Gehäuse

An dieser Stelle sei noch einmal daran erinnert, dass man die Gefahren durch elektromagnetische Beeinflussung nicht unterschätzen sollte. Die optoelektronische Trennung verhindert in erster Linie, dass man sich Störsignale über das RS232-Schnittstellenkabel einfängt. Vor direkter Hochfrequenzeinstrahlung schützt diese Maßnahme nur bedingt. Gegen elektrische und magnetische Wechselfelder hilft nach wie vor nur ein Metallgehäuse. Dieses sichert die elektromagnetische Unabhängigkeit des Zufallsgenerators auch unter erschwerten Bedingungen (hausgemachte Störstrahlung aus Computerkomponenten, Angriffe durch sogenanntes HF-Fluten ...).
Beim Einbau in ein HF-dichtes Metallgehäuse kann und soll das Chassis auf direktem Weg mit Schaltungsmasse verbunden werden. Dafür ist der Erdungspin zwischen IC1/IC2 vorgesehen (siehe Bestückungsplan). Die Betriebsspannungsbuchse muss dann allerdings isoliert eingebaut werden, oder man sieht auch auf dieser Seite eine feste Kabeldurchführung mit Gummitülle vor.

Mit der Schaltungsversion 2.0 ist der Zugriff nun wirklich kinderleicht geworden.
Die Nutzung des XR232 lässt sich jetzt ohne Weiteres "sprachübergreifend" erklären:

1. Port öffnen (DTR geht auf +12V)
   (ggf. eine Sekunde warten, bis sich die Hilfsspannung aufgebaut hat)
   
2. Taktzeichen senden
3. Auf Zeicheneingang im Empfangspuffer warten (wenn keines oder zwei Zeichen eintreffen -  Fehler! Weiter bei 7!)
   
4. Zufallszeichen abholen
5. Wenn mehrere Zufallszeichen gewünscht, weiter bei 2, sonst:
6. Port schließen (DTR geht wieder auf -12V, Bitzähler wird gesetzt und gesperrt)
   
   
7. Fehlerbehandlung:
   Port schließen; eine Sekunde warten; Port wieder öffnen; eine Sekunde warten; Taktzeichen senden; Zurück.
   

Von meiner Seite stehen weiterhin ein paar Demoprogramme (Punkt [11] der Linkliste) in QBasic sowie das DOS-Kommandozeilentool XR232.EXE zum Download zur Verfügung. Das DOS-Tool ermöglicht die wichtigsten Funktionstests des XR232, aber auch die Erzeugung größerer Zufallsdateien, wobei man verschiedene Balancierungsoptionen anwenden kann. Dieses Tool läuft unter DRDOS, Open-DOS, MSDOS (ab Version 4.0) sowie in einem Fenster unter Win9x.

Längst sind auch zwei aktuellere Entwicklungen für Linux in Gang gekommen; insbesondere möchte ich auf die Projekte [9] und [10] in der unten stehenden Linkliste hinweisen!

---

Anmerkungen

Abschirmung

Die Unabhängigkeit von Zufallszahlen ist keine Qualität, die man ausschließlich an statistischen Testergebnissen festmachen könnte -  genau genommen gibt es überhaupt kein mathematisches Verfahren, mit dem sich echter Zufall "beweisen" ließe. Eine Tatsache, die die meisten kommerziellen Anbieter von Zufallsgeneratoren im Zusammenhang mit verdächtig guten Testergebnissen ihrer Produkte geflissentlich verschweigen.
Es kommt noch schlimmer: Manch guter Pseudozufallsgenerator besteht eine ganze Reihe von statistischen Testverfahren (z.B. [2]) mit Bestnote. Und von Pseudozufallsgeneratoren wissen wir eines ganz genau: Dass sie mit echtem Zufall garnichts zu tun haben!
Bei logischer Betrachtung ist diese Tatsache dann doch nicht mehr so verwunderlich. Pseudozufallsgeneratoren sind Algorithmen, und die kann man gezielt darauf zuschneiden, bestimmte mathematische Eigenschaften zu haben. Statistische Testverfahren sind ebenfalls Algorithmen. Wir haben also mathematisch erzeugte Ergebnisse mit mathematischen Verfahren getestet...
Was sind statistische Testverfahren also wert, wenn man sie auf echte Zufallsdaten anwendet? Anscheinend können statistische Testverfahren immer nur Indizien dafür liefern, inwiefern die untersuchte Zahlenmenge bestimmte statistische Kriterien erfüllt, die man auch dem echten Zufall zuschreibt. Das ist ja garnicht mehr so doll!
Besonders unangenehm bei der ganzen Sache: Auch unterschwellig vorhandene Störungen eines echten Zufallsgenerators ließen sich mit mathematisch-statistischen Methoden nur schwer nachweisen. Anomalien bei Zufallsgeneratoren sind sicher ein hochinteressantes Thema (z.B. sowas hier), das weit über die Kryptografie hinausgeht und das ich hier auch garnicht mit ein paar polemisch in die Tasten gehämmerten Worten abhandeln will. Aber solange in diesem Universum physikalische Gesetze gelten, muss man nicht unbedingt "Psi-Kräfte" dafür verantwortlich machen, wenn ein Zufallsgenerator scheinbar verrückt spielt - oft genügen schon Netzschwankungen, ein WLAN-Access-Point oder ein achtlos liegengelassenes Mobiltelefon in der näheren Umgebung, um ein allzu primitives oder auch allzu komplexes Schaltungskonzept aus der Ruhe zu bringen...!

Neuzeitliche CPUs mit "Zufallsgenerator" on Chip ?

Echter Zufall lässt sich bekanntlich nicht mit Standardkomponenten eines gewöhnlichen PC-Systems erzeugen. Aber auch gegenüber Systemkomponenten, die vorgeben, speziell für Kryptoanwendungen entwickelt worden zu sein, ist ein gesundes Misstrauen sicher angebracht. So haben einige neuzeitliche CPUs bereits einen "echten Zufallsgenerator" on-chip [4]. Wäre das nicht eine superelegante und leistungsfähige Methode zur Generierung von Zufallszahlen und kryptografischen Schlüsseln? Ja, das wäre es, wenn man sich allein auf Pressemitteilungen verlassen könnte und sämtliche physikalischen Gesetzmäßigkeiten einmal außer Acht lässt... Nein, aus zwei Gründen: Zum einen erscheint es schon ziemlich gewagt, eine elektronische Rauschquelle in einem Umfeld betreiben zu wollen, in dem es vor Hochfrequenzstrahlung nur so wimmelt. Rauschquelle mitten auf einem Prozessor, das kann eigentlich nur ein Aprilscherz sein. Doch nach Angeben des Herstellers beruht die P**lock Engine ja ausdrücklich auf einer elektronischen Zufallsquelle, also thermisches Rauschen oder Zener-Rauschen, nicht etwa auf einem quantenoptischen Zufallsgenerator. Diese imaginäre Rauschquelle könnte selbst unter Anwendung ausgeklügelter symmetrischer Signalverarbeitungskonzepte nicht wirklich unabhängig arbeiten. Wenn das Ding trotzdem scheinbar unabhängige Zufallszahlen produzieren kann, dann liegt die Schlussfolgerung nahe, dass es sich in Wirklichkeit um einen komplexen Pseudozufallsgenerator handelt. Somit hat diese Implementierung auch garantiert keine "Hintertürchen" - sie IST ein einziges Hintertürchen!

Zukunftsperspektiven RS232 / USB

Eins vorweg: Nicht nur meiner Einschätzung nach wird RS232 auf industriellen, wissenschaftlichen und medizinisch genutzten Plattformen, also überall, wo Computer ernsthaft eingesetzt werden, vielleicht nicht "für immer", aber doch für sehr lange Zeit verfügbar bleiben. Ganz einfach, weil diese Schnittstelle dort noch immer massenweise benutzt wird, zum Beispiel für Messgeräte, Steuerungen, oder eben für hochwertige externe Zufallsgeneratoren ;-)

Dass die Situation auf dem "Consumer"-Sektor ganz anders aussieht, ist auch klar. Vor etwa zehn Jahren wurde USB eingeführt, und seitdem hört man von einigen Mainboardherstellern immer wieder die wüste Behauptung, RS232 sei "veraltet" / "am aussterben" / "zu teuer". Klar, dass man lieber USB und Firewire pushen will, denn kurzlebige Geräte, die ausschließlich mit noch kurzlebigeren Treibern zusammen funktionieren, bringen einfach mehr Kohle rein!
Dann sollte man aber auch so ehrlich sein, und diese rein marktpolitischen Überlegungen offen zugeben. Es ist nämlich kein zusätzlicher Aufwand und praktisch kein zusätzlicher Kostenfaktor, wenn man von einem Multi-I/O-Chip nicht nur die Ethernet/1394/USB-Leitungen herausführt, sondern auch gleich noch ein paar anspruchslose RS232-Leitungen auf das Board verlängert. Die fadenscheinige Begründung, ein RS232-Pinheader würde "zuviel Platz auf dem Board wegnehmen", will nicht so recht überzeugen. Mancher Hersteller, hier sei VIA einmal ausdrücklich lobend erwähnt, bringt es sogar fertig, auf einigen seiner ITX-Boards noch zwei RS232-Ports unterzubringen!
Für den Consumer, der dummerweise auf ein unvollständig ausgestattetes Mainboard ohne RS232 reingefallen ist, gibt es immerhin noch die Alternative einer sündhaft teuren Erweiterungskarte, oder eines sogenannten USB-COM-Adapters. Damit wäre das Problem "Weiterverwendung von RS232-Geräten auf sogenannten modernen Computern" im Grunde schon gelöst.
Dennoch werde ich beizeiten mal eine USB-Variante des XR232 in Betracht ziehen. Diese würde auf einem FT232xx-Chip aufsetzen, welcher ebenfalls ein USB/COM-Interface darstellt, nur eben mit reinen TTL-Pegeln auf der RS232-Seite. Man könnte den XR232-"Kern" direkt an dieses Interface anbinden und die Schaltung dann bequemerweise direkt über USB mit Strom versorgen (was ja Sinn der Sache wäre). Allerdings müsste man gleichzeitig auf zwei der wichtigsten Sicherheitsmerkmale des ursprünglichen XR232-Konzeptes verzichten: die galvanische Trennung und die elektromagnetische "Neutralität", die man mit der jetzigen Schaltung erreicht.

Nach oben

---

Mitmachen?

Der "XR232" ist DAS Open-Source-Projekt eines unabhängigen Hardware-Zufallsgenerators für die serielle Schnittstelle, welcher auf bewährten Techniken  und preiswerten Bauteilen beruht. Der XR232 liefert vorbalancierte Rohdaten von guter Qualität mit bis zu 57600 Baud an die serielle Schnittstelle. Die Übertragung entspricht zu jedem Zeitpunkt den RS232-Standards, sodass die Ansteuerung auf nahezu jeder Rechnerplattform mit Standardtreibern möglich ist. Hierfür kommt ein simples Challenge-Response-Protokoll zum Einsatz, das möglicherweise als kleinster gemeinsamer Nenner für Zufallsgeneratoren an einem echten oder virtuellen seriellen Port geeignet ist.

Inzwischen stehen einige Programmierbeispiele für DOS/Windows und sogar Gerätetreiber für Linux-Systeme zur Verfügung. Auch diese Projekte sind Open-Source und über die verschiedenen URLs der jeweiligen Autoren verfügbar. Bitte haben Sie Verständnis, dass ich mich vor allem auf die Hardwareseite und die von mir gepflegte DOS-Software konzentriere! In diesem Rahmen stehe ich aber gern für Anregungen und Rückfragen zur Verfügung.

Höchst interessant wäre eine direkt verwendbare Einbindung des XR232 in echte Killer-Applikationen, wie etwa PGP/GNUPG. Wer sich beispielsweise mit Treiberprogrammierung auskennt und die Idee eines Quasi-Standards für robuste und transparente TRNG-Hardware gut findet, den bitte ich herzlichst, das Projekt zu unterstützen und sich mit mir in Verbindung zu setzen!

Platinen oder Bausätze kann ich zum Selbstkostenpreis zusammenstellen. Bei Interesse bitte mailen!


Nach oben

Links

[1] Prinzipien zu Rauschquellen, Rauschverstärkern (Englisch):  http://www.ciphersbyritter.com/RES/NOISE.HTM

[2] DIEHARD-Testbatterie (der Klassiker): http://www.stat.fsu.edu/pub/diehard/

[3] Anwendungen von Zufallsgeneratoren, Kryptografie, Zufallsforschung:
www.staff.uni-mainz.de/pommeren/DSVorlesung/KryptoBasis/Zufall.html
www.ibbergmann.org/1633700.htm
www.world.std.com/~reinhold/truenoise.html
www.infotech.tu-chemnitz.de/
www.kuno-kohn.de/crypto/crypto/prngs.htm
www.allemannda.de/Deutsch/Computer/Sicherheit.htm

[4] Obskur, proprietär, esoterisch überladen, kommerziell und hoffnungslos überteuert (oder alles zusammen):
www.westphal-electronic.com
http://noosphere.princeton.edu/index.html
www.true-random.com/index.htm
www.m-tec.ag
www.via.com.tw/en/initiatives/padlock/hardware.jsp

[5] Thomas, Julien: "Zufallsgenerator für die serielle Schnittstelle" FA 12/01, S.1337ff

[6] Thomas, Julien: "Potenzialfreie Pegelwandlung für die RS232-Schnittstelle" FA 11/05, S.1140-1141

[7] Wissenswertes zu RS232/EIA-232 von Wikipedia http://de.wikipedia.org/wiki/RS232

[8] Download der ersten XR232-Demosoftware (DOS) im Download-Archiv des FA, Stichwort "XR232": www.funkamateur.de

[9] Zum auf Linux beruhenden XR232-Projekt von Meinhard Schneider: http://xr232.dl1fms.de/

[10] Das brandneue Projekt "xr232random" für Linux von Jochen Brenner: http://www.xr232.noedit.de

[11] Julien's Paket aus XR232-Schaltunterlagen und DOS-Tool

---

---