XR232 - Echter Zufall und echtes RS232-Protokoll


Beim vorliegenden Open-Source-Konzept eines kryptografischen Zufallsgenerators stehen Hardwaresicherheit und Transparenz im Vordergrund. Dieser Zufallsgenerator beruht auf bewährter Technik, ist lückenlos dokumentiert, und er liefert dem PC über reguläre RS232-Zugriffe garantiert unabhängige Zufallszahlen mit bis zu 57600 Baud.

Projekt | Technik | Protokoll | Abschirmung | Hardware | Software | Aufbau | Test | Anmerkungen | Mitmachen | Links | Index


Bild 1:
XR232
im Metallgehäuse
Die neue Version
  • Unabhängige Plattform
  • Unabhängige Zufallszahlen
  • Echter RS232-Zugriff
  • Transparenz
  • Standardbauteile
  • Externes Gerät
  • Hohe Störsicherheit
  • Open-Source-Projekt



Echter Zufall für alle

Wenn Sie, lieber Leser, "zufällig" auf dieser Seite gelandet sind und eigentlich eine Black-Box mit zweifelhaftem Innenleben, proprietärer Klickibunti-Software, sagenhaften Statistiken und fest eingebauten Hintertürchen für schlappe 500 Dollar gesucht haben, ja, dann muss ich Sie leider auf die Seiten einschlägiger Internetgeschäftemacher  verweisen ... ! (Beispiele unter [4])

"XR232" ist ein solides Hardwarekonzept für einen kryptografischen Zufallsgenerator, der auf preiswerten Standardkomponenten beruht und selbstverständlich vollkommen offen dokumentiert ist. Der XR232 ist "unbezahlbar", da es ihn nicht als Fertiggerät zu kaufen gibt. Dafür kann sich jeder interessierte Elektronikamateur ein solches Gerät für etwa 20 Euro Materialkosten selbermachen.

Der XR232 liefert vorbalancierte Rohdaten von guter statistischer Qualität mit bis zu 57600 Baud an die serielle Schnittstelle. Die sichere Mindest-Datenrate mit unselektierten Bauteilen an einer eher schwachen RS232-Schnittstelle beträgt 19200 Baud. In der Regel sind 38400 Baud sicher erreichbar. Die Datenübertragung findet zu jedem Zeitpunkt streng nach RS232-Protokoll statt - insbesondere werden für den Zugriff keine obskuren Treiberkonstrukte benötigt. Schon mit einem einfachen Terminalprogramm für die serielle Schnittstelle lässt sich die Funktionstüchtigkeit des Zufallsgenerators testen. Wenn eine Software den XR232 nutzen will, muss sie lediglich Standardzugriffe auf die serielle Schnittstelle beherrschen. Tatsächlich ist die Anwendung des XR232 und die Portierbarkeit seiner Software zwischen verschiedenen Rechnerplattformen nun offensichtlich kein Problem mehr. In der Linkliste sind die aktuellen XR232-Programmierprojekte aufgelistet.

Als Zufallsquelle mit hervorragendem Preis-Leistungs-Verhältnis nutzt der XR232 eine Z-Diode. Die Schaltungstechnik ist damit im Vergleich zu thermischen Rauschgeneratoren bereits relativ unempfindlich gegen elektromagnetische Störungen. Dennoch schien es angebracht, das gesamte System des Zufallsgenerators gewissermaßen "ganzheitlich" auf Robustheit zu trimmen.
Daher verwendet der XR232 selbstverständlich seine eigenen gefilterten Betriebsspannungen, eine Abschirmung für die Rauschquelle, eine optoelektronische Schnittstellenanbindung zum PC-System, und empfehlenswert ist darüber hinaus der Einbau in ein Vollmetallgehäuse, wie in Bild 1 zu sehen.

Mit diesem bodenständigen Hardwarekonzept werden also, keinen Tag zu früh, drei der wichtigsten Grundvoraussetzungen für vertrauenswürdige Zufallsanwendungen erfüllt:

Transparente Hardware - Transparentes Protokoll - Transparente Software!

Nach oben



Allgemeines zur Technik

Zufallsquelle

Der Rauscheffekt einer Z-Diode entsteht durch zwei subatomare Effekte, die sich in der Raumladungszone des Halbleiterkristalls abspielen: das sogenannte Schrotrauschen sowie den Avalanche-Effekt. Beide haben einen starken quantenphysikalischen Hintergrund. Das Rauschen einer Z-Diode ist daher ein echtes analoges Zufallssignal. Mit einer entsprechend beschalteten Z-Diode kann man, je nach Typ und Betriebsstrom, ein Rauschsignal generieren, das einen Pegel von mehreren Millivolt und eine Bandbreite von mehreren hundert Kilohertz aufweist. Dieses relativ starke Signal lässt sich mit unkritischen Verstärkerkonzepten anheben und dann sehr schnell in eine robuste digitale Signalform überführen.
In der vorliegenden Schaltung arbeitet eine handelsübliche Kleinleistungs-Z-Diode 9,1V in einer selbststabilisierenden und somit abgleichfreien Verstärkerschaltung. Das Konzept ist nicht auf maximale Ausbeute an Bandbreite, sondern auf maximale Betriebssicherheit ausgerichtet. Mit nur einer weiteren Transistorstufe kommt man bereits auf Digitalpegel. Dieses Signal wird mit Hilfe eines Teiler-Flipflops auf rein digitalem Weg ausbalanciert. Man bekommt auf diese Weise einen Zufalls-Bitstrom, der nur noch um wenige Promille von der idealen Gleichverteilung abweicht, aber weiterhin eine Bandbreite in der Größenordnung von 100 kHz aufweist. Aus diesem Zufalls-Bitstrom holt sich der angeschlossene Computer seine Zufallsdaten per Sample-and-Hold-Zugriff in Unterabtastung. Und jetzt kommt's:

Echter RS232-Zugriff

Das Bitsampling erfolgt beim XR232 nicht über zweckentfremdete Statusleitungen und spezielle Treiber, sondern ausschließlich im Rahmen des RS232-Protokolls, dessen Anforderungen man unter anderem bei [7] nachlesen kann.

Die vorliegende XR232-Hardware ist sofort einsatzbereit, nachdem die Schnittstelle standardgemäß initialisiert wurde. Nun kann der PC über die Leitung TXD ein bestimmtes Kommandozeichen an den XR232 senden. Der XR232 antwortet über die Leitung RXD mit einem Zufallszeichen, welches selbstverständlich ein gültiges serielles Zeichen ist. Die Funktion lässt sich sogar mit diversen Terminalprogrammen direkt testen.

Der technische Mehraufwand erscheint insbesondere deswegen gerechtfertigt, weil die echte RS232-Übertragung durch den UART abgewickelt wird. Der UART-Chip übernimmt bereits elementare Sicherungsfunktionen der Übertragung (ISO-Schichten 1 und 2). Der UART erledigt alle zeitkritischen Jobs, wie etwa das Timing für die Codierung und Decodierung serieller Bits auf den Leitungen TXD/RXD, aber auch die Synchronisation auf Start- und Stoppbits, eine einfache Fehlererkennung (Paritätsbits), Verwaltung eigener FIFO-Puffer und die Einhaltung der Sequenzregeln (Hardware-Handshake).
Man kann sich in der Regel darauf verlassen, dass der UART selbst dort, wo er als Teil eines Multi-I/O-Chips oder nur noch als USB-RS232-Adapter realisiert ist, sehr autonom und zuverlässig arbeitet.

Jede vernünftige UART-Implementierung ist daher gegenüber Angriffen durch "feindliche Drittsoftware" ziemlich immun. Es ist zwar vorstellbar, dass man (mit direkten Zugriffsrechten auf Hardwareadressen) eine RS232-Datenübertragung irgendwie sabotieren kann, aber die gezielte und unbemerkte Beeinflussung im Sinne einer Einspeisung von Pseudo-Zufallsdaten, erscheint doch sehr unwahrscheinlich.

Also nochmal im Vergleich:
Für den Programmierer bedeutet das: Weil der UART also schon einen erheblichen Teil der "Drecksarbeit" übernimmt, ist RS232-Kommunikation auf Hochspracheebene eigentlich eine recht bequeme Angelegenheit. Der UART wird über Standardtreiber des Betriebssystems bzw. Standardprozeduren der jeweiligen Entwicklungsumgebung angesprochen. Man muss sich insbesondere nicht mehr mit Hardware-Adressen, Interrupts und Realtime-Anforderungen herumschlagen. Meist lassen sich die seriellen Schnittstellen über ein Kanal- oder Dateimodell ansprechen. Das funktioniert sogar über mehrere Ecken, etwa, wenn der serielle Port in Wirklichkeit über einen USB-Adapter emuliert wird ("virtuelle serielle Schnittstelle").


Nach oben


Bitte acht Bit !

Zur Darstellung eines normgerechten seriellen Datenstroms benötigt man auf der Seite der Peripherie nicht zwangsläufig einen UART oder gar einen Mikrocontroller - Für ein einfaches "Challenge-Response"-Protokoll tun's auch ein paar trickreich verschaltete Logikgatter. Diese Umsetzung bleibt schaltungstechnisch transparent, ist ausgesprochen manipulationssicher und sie kommt ohne eigenen Taktgeber aus.

Natürlich braucht man zur Generierung von seriellen Zeichen eine halbwegs genaue Taktfrequenz von mindestens der doppelten Baudrate. Das ist eine Herausforderung, denn die erforderliche Frequenzgenauigkeit für einen RS232-Baudratengenerator ließe sich nur über einen relativ hochfrequenten Oszillator mit vielfacher Taktteilung erreichen. Mit einem solchen Oszillatorbaustein "onboard" hätte man allerdings eine hochfrequente elektromagnetische Störquelle in unmittelbarer Nähe zur Rauschquelle; selbst mit aufwendigen Abblock- und Abschirmmaßnahmen ließe sich kaum verhindern, dass es zu einer unerwünschten Rückwirkung auf die Rauschquelle kommt.

Aber woher soll der Takt denn sonst kommen? Ganz einfach - vom UART der PC-Schnittstelle! Es gehört ja schließlich zu seinem Job, serielle Zeichen in genau festgelegten Baudraten zu senden! Und so funktioniert's:
Für jedes einzelne Zufallsbyte, das gelesen werden soll, sendet der UART über die Leitung TXD ein bestimmtes serielles Zeichen, nämlich das "U" (ASCII-Code, 55hex). Dieses Zeichen entspricht in der Übertragungsart 8-N-1 der binären Bitfolge 0-10101010-1. Hier bekommt man also mit jedem Taktschritt einen Pegelwechsel, einschließlich der Übergänge zu den Start- und Stoppbits. Damit steht dem Zufallsgenerator eine genaue "Takt-Schablone" zur Verfügung, mit der er nun seinerseits jedes beliebige serielle (Zufalls-)Zeichen generieren kann!
Es genügt allerdings nicht, die Zufallsbits einfach nur mit den zurückgewonnenen Taktimpulsen abzutasten und diesen Bitstrom auf RXD zu geben. Dort, wo die serielle Übertragung Start- und Stoppbits verlangt, darf man selbstverständlich nichts dem Zufall überlassen, anderenfalls würde der UART die meisten ankommenden "Zeichen" als ungültig verwerfen. Also müssen wir für die Übertragungsart 8-N-1 auch noch die Taktschritte mitzählen und jeden 1. und 10. Taktschritt feste Startbits und Stoppbits in den laufenden Datenstrom einprägen. Das lässt sich mit einem Dezimalzähler und ein paar logischen Verknüpfungen bewerkstelligen - und fertig ist das normgerechte serielle Datensignal - siehe Timingdiagramm!
Die über RXD zurückgelieferten seriellen Zeichen nimmt der UART dankbar entgegen und legt sie in seinem Empfangspuffer ab. Dort kann die steuernde Software diese Zufallszeichen nun in aller Ruhe auslesen und weiterverarbeiten.
Netter Nebeneffekt: Der Zufallsgenerator antwortet automatisch in derselben Geschwindigkeit, mit der der UART im PC seine Takt-Zeichen gesendet hat. Bis zu einer hardwarebedingten Maximalgeschwindigkeit von etwa 57600 Baud kann man den XR232 in jeder gültigen Baudrate ansprechen, ohne dass am Gerät irgendetwas neu konfiguriert werden müsste.

Die Vorzüge dieser Lösung noch einmal im Überblick:

Der XR232-Zufallsgenerator benötigt keinen eigenen Taktgeber.
Kein hochfrequenter Taktgeber "onboard" bedeutet: Keine hausgemachte Störstrahlung, die das Rauschsystem beeinflussen könnte!


Die XR232-Software muss lediglich ein bestimmtes serielles Zeichen über die RS232-Schnittstelle senden.
Im Gegenzug bekommt sie dafür vom XR232 genau ein echtes serielles Zufallszeichen zurückgesendet.
Das sind einfache und unkritische Standardzugriffe, die von jeder Programmierumgebung unterstützt werden.






Timingdiagramm XR232
Bild 2: Zur Erzeugung des seriellen Datenstroms beim XR232

Nach oben




Das Blech

Harte Hardware, weicher Kern. Der sensibelste Teil jedes echten Zufallsgenerators verwendet notgedrungen Analogelektronik. Egal, ob man als Zufallsquelle Strahlen- oder Photodetektoren, rauschende Widerstände, überkritische Oszillatoren oder eben eine Z-Diode einsetzt, immer stellt sich das Problem, dass man ein relativ schwaches elektronisches Nutzsignal verstärken muss, bevor man es in eine robuste digitale Signalform überführen kann. Vielleicht werden die Computer des nächsten Jahrhunderts einmal komplett auf Lichtblitzen beruhen, aber bis auf Weiteres bleibt genau diese analogelektronische Seite die "Achillesferse" eines Zufallsgenerators: Jeder Messverstärker, der schwache Signale elektronisch verstärkt, ist mehr oder weniger angreifbar durch Einstrahlung von Hochfrequenz.

Wenn wir in jeder Hinsicht unabhängige Zufallszahlen produzieren wollen, dann darf sich die Hardware natürlich nicht durch ein ungünstiges Geräteumfeld oder einen gezielten Strahlenangriff beeinflussen lassen ... !

In der vorliegenden Schaltung wurden die grundlegenden "Design-Rules" zur Vermeidung unnötiger EM-Anfälligkeit berücksichtigt:
Separate und gefilterte Betriebsspannungen für Analog- und Digitalteil; kompakter und abgeschirmter Aufbau der Rauschquelle; Abblockkondensatoren für digitale Logikbausteine; Vermeidung oberwellenreicher Signalformen; keine unnötig hohen Taktfrequenzen onboard.

Durch diese Maßnahmen produziert die Schaltung einerseits wenig Eigenstörungen und wird andererseits relativ unempfindlich gegenüber externen Störsignalen, etwa durch Mobiltelefone oder WLAN-Adapter.

Und dennoch: Gegen einen gepulsten kleinen Mikrowellenstörsender in unmittelbarer Nähe (vulgus "Handy") sind die meisten elektronischen Geräte machtlos, sofern keine zusätzlichen Abschirmmaßnahmen getroffen werden. Dazu ein kleiner Test:

GSM-Mobiltelefon, Anmeldung an der Basisstation mit voller Sendeleistung (ca. 750mW ERP).
Das "Handy" wird in etwa 15 cm Abstand zur ungeschirmten Rauschquelle des XR232 platziert. Ergebnis unten rechts!




Bild 3a:
Gut: Unverdächtiges Pixelmuster vom XR232 @ 38400 bps (Pixeldarstellung mit dem XR232-Tool;
Ausschnitt 1/4 VGA-Schirm).
Bild 3b:
Weniger gut: Sichtbare EM-Beeinflussung durch 1800MHz-Impulse aus einem GSM-Telefon (in ca. 15 cm Abstand zur nackten Rauschquelle)


Gegenmaßnahme

So dramatisch diese störende Beeinflussung auch wirkt, für den HF-Techniker war sie vorhersehbar... Aber schon ein Blechhäubchen für die Rauschquelle brachte die Störmuster wieder zum Verschwinden. Die Abschirmung dürfte für den gesamten VHF- , UHF- und Mikrowellenbereich wirksam sein. Dasselbe "Handy", mit dem vorher die im rechten Bild gezeigten Störungen provoziert wurden, musste nach Auflöten der Bleche (Oberseite und Unterseite der Platine) schon auf weniger als 2 cm an den XR232 herangebracht werden, damit überhaupt wieder ein messbarer Effekt auftrat. Im Platinenlayout habe ich daher Lötstützpunkte für die Befestigung einer solchen Abschirmhaube fest vorgesehen.

Aber es geht noch besser... In Bild 1 wurde bereits die Heavy-Metal-Version einer vernünftigen Geräteabschirmung gezeigt: Vollmetallgehäuse, gegebenenfalls eine Verdrosselung der Betriebsspannung, und natürlich die optoelektronische Trennung der RS232-Schnittstelle - das sieht nicht nur schick aus, es ist ein sinnvolles Maßnahmenpaket, mit dem sich der Zufallsgenerator schon sehr breitbandig von der Außenwelt abschirmen lässt.
Die Schutzwirkung dieser Variante geht bis hinunter in den VLF-Bereich (Schaltnetzteile, CRT-Monitore). Paranoid sicher wäre die Sache mit einer reinen Batteriespeisung, wenn man alle Komponenten in einem Metallkasten unterbringen würde. Dazu weiter unten noch einige Anmerkungen.

Nach oben



Schaltung


Schaltplan XR232

Bild 4:
Schaltplan XR232 Version 2.2 - Zum Vergrößern bitte anklicken!



Schaltungsdetails

Stromversorgung

Der Zufallsgenerator kann mit Wechselspannung 9...14 V oder Gleichspannung 12...20 V versorgt werden.

Für die Wechselstrom-Option hat der XR232 seine eigene Gleichrichterbrücke "on board". Auf diese Weise können zum Beispiel die robusten Wechselstrom-Steckernetzteile für analoge Modems und Anrufbeantworter (9...12 VAC) nutzbringend weiterverwendet werden. Diese Netzteile enthielten nur einen hochwertigen und meist kurzschlussfesten Trafo in Zweikammerbauweise. Durchschlagfest bis zu mehreren kV, das bedeutet eine sehr geringe kapazitive Kopplung ins 230-V-Netz. Impulsstörungen aus dem Stromnetz konnten kaum bis zum angeschlossenen Verbraucher vordringen, und insbesondere in der Kombination mit Festnetz-Telefongeräten war ein hoher Sicherheitsstandard garantiert. Außerdem hat ein einfacher Trafo den unschlagbaren Vorteil, dass er garantiert keine hochfrequenten Eigenstörungen produziert. Leider ist diese Bauweise heute kaum noch als Fertiggerät zu beschaffen. Der Selbstbau mit hochwertigen vergossenen Printtrafos ist natürlich weiterhin eine Option!

Für die Speisung mit Gleichstrom stehen heute vor allem Schaltnetzteile zur Verfügung. Damit wird es nie langweilig, denn die Billigen gehen auch schnell kaputt, damit sich die Rohstoffverschwendungsspirale immer schön weiter dreht. Obendrein wird es auf der Sekundärseite manchmal erstaunlich "kribbelig", weil die kapazitive Kopplung ins Energienetz meist viel höher ist, als bei einem konventionellen Trafo. Ableitspannungen um die 100 Volt, das kommt beim Zusammenstöpseln mit empfindlicher IT-Elektronik natürlich besonders gut an... Überflüssig zu sagen, dass man von einem Stecker-Schaltnetzteil für 7,99 auch keine wirklich saubere Gleichspannung erwarten darf, wie sie etwa für den Betrieb von Audioschaltungen benötigt würde.

Der zulässige Eingangsspannungsbereich ist aber relativ groß. Selbstverständlich funktioniert der XR232 auch mit einem stabilisierten Netzteil oder einem Schaltnetzteil von genau 12 V Nennspannung. Besser wären 15 V. Der Maximalwert, bei dem der Betrieb des Spannungsregler-ICs ohne Kühlkörper noch vertretbar erscheint, liegt bei etwa 20 V. Somit besteht also auch die Option eines Notebook-Netzteils, auch wenn dieses kaum ausgelastet und mit relativ schlechtem Wirkungsgrad arbeiten wird.

Der Digitalteil ist da anspruchsloser. Die gesiebte Gleichspannung an C5 geht auf den erwähnten Festspannungsregler VR1 (7805), der den Digitalteil mit stabilen 5 V versorgt. An dieser Stelle kommt selbstverständlich nur ein konventioneller Linearregler infrage, der von sich aus keine hochfrequenten Störungen verursacht! Daher bitte auch den 100-nF-Kondensator C7 nicht vergessen, dieser verhindert eine Selbsterregung des Spannungsreglers.
Der Strombedarf des Digitalteils beträgt nur maximal 60 mA. Bis ca. 12...16 V unstabilisierter Eingangsgleichspannung benötigt der Regler im TO-220-Gehäuse garantiert keinen zusätzlichen Kühlkörper.
Selbst im Wärmestau bei einer unstabilisierten Eingangsspannung von 20 V erhitzte sich VR1 nie auf mehr als 50 Grad Celsius (Messwert Strahlungsthermometer). Das ist weniger, als manches Bauteil auf PC-Hauptplatinen vor sich hinbrutzelt! Mit einem kleinen Kühlblech oder bei Chassismontage sind Eingangsspannungen bis ca. 24 VDC problemlos möglich.
Wer nur mit Gleichspannungsnetzteilen arbeiten will, könnte eine verpolsichere Buchse verwenden und direkt auf C5 gehen. Besser ist es allerdings, den Verpolschutz durch die Diodenbrücke weiterhin zu nutzen. Die HF-Abblockkondensatoren C1-C4 (47 nF) filtern zusätzlich mögliche Störungen aus dem Schaltnetzteil.


Rauschquelle

Die Rauschquelle (Bauteile mit vorangestelltem "X") beruht auf einer Kleinleistungs-Z-Diode 9V1 (z.B. Standardtyp C9V1, Philips) und zwei bipolaren NPN-Transistoren (Standardtyp BC547B/C).
Die "Rauschdiode" XZD liegt gleichstrommäßig im Gegenkopplungszweig der Emitterschaltung XVT1/XR1/XR2. Ab einer Mindest-Betriebsspannung, die ein paar Volt über der Z-Spannung liegen sollte, stabilisiert sich die Schaltung automatisch auf einen Arbeitspunkt, an dem die Diode permanent im Bereich des Kennlinienknicks betrieben wird, also den maximalen Rauschbeitrag liefert. Die Schaltung ist somit 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, sodass auch die hochfrequenten Rauschanteile praktisch ungedämpft an die Basis von XVT1 gelangen. Dieser verstärkt das Rauschen, übrigens noch annähernd linear, um ca. das 250-fache. Am Kollektor von XVT1 steht ein Nutzsignal in der Größenordnung von bis zu 1VSS.
Über XC2 gelangt der Wechselstromanteil dieses breitbandigen Rauschens auf die zweite Stufe mit XVT2/XR3. Sie hebt das Signal bis in die Begrenzung an. Der Kollektor von XVT2 liefert (über den externen Pullup R3) somit ein digitaltaugliches Eingangssignal für die nachfolgende Stufe.

Balancierung

Das digitalisierte Rauschen geht auf den Takteingang des als Frequenzteiler verschalteten ersten Flipflops von IC3a (74LS74, Pin 3).
Als digitales Balancierungsverfahren ist die Frequenzteilung 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 zeitvariablem Roh-Datenstrom holt sich der angeschlossene Computer mit dem aus zurückgewonnenen Bit-Takt jeweils ein Zufalls-Datenbit (D-Flipflop in IC3) genau mit der 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 ein Taktzeichen (0-10101010-1), so 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.

Anmerkung zu D5/D6 in Schaltungsversion 2.1: Inzwischen empfehle ich, an dieser Stelle keine Silizium-Dioden einzusetzen, sondern Schottky-Dioden vom Typ BAT42, die einen geringeren Spannungsabfall aufweisen. Auf diese Weise geht man sicher, dass selbst "grenzwertige" Exemplare des 74LS74 in dieser Schaltung das Taktsignal sauber auswerten können. (LOW-Pegelbedingung an Pin 11) Wichtig: Wer die Schaltung bisher mit einem HCMOS-Baustein (74HC74, 74HCT74) betrieben hat, kann die Si-Dioden beibehalten - hier liegt die Schaltschwelle etwa auf Höhe der halben Betriebsspannung.

Zufalls-Bitsampling

Die aus TXD abgeleiteten Taktimpulse gehen direkt auf den Takteingang des zweiten D-FF in IC3b (Pin 11). Es speichert den zum Abtastzeitpunkt vorliegenden Logikpegel bis zum nächsten Takt. An den Q-Ausgängen stehen nun serielle Bits, die bereits genau dem Zeitraster der aktuell eingestellten Baudrate entsprechen. Zum normgerechten RS232-Datenstrom fehlen allerdings noch zwei Kleinigkeiten...

Generierung der Start- und Stoppbits

Im fortlaufenden Zufalls-Bitstrom müssen an den richtigen Stellen Start- und Stoppbits vorliegen. Dazu müssen die über TXD gelieferten Taktimpulse abgezählt werden. Diese Aufgabe übernimmt IC2 (Dezimalzähler 74LS90). Er liefert im Abstand von 10 Takten an seinem Ausgang Qd (Pin 11) ein 2 Takte breites Zeitfenster, in dem je ein Stopp- und ein Startbit eingefügt werden. (Anmerkung: Nur die fallenden Flanken triggern den Zähler, daher muss man auch nur das Teilersystem "durch 5" für diesen Zweck benutzen.)
Durch Verknüpfung von TXD-TTL mit Qd und zeitnahes Setzen der R/S-Eingänge von IC3a/b über Verzögerungsglieder (R4/C9, R6/C10) erreicht man, dass das 1.Bit grundsätzlich LOW-Pegel ("Startbit") bekommt, während als 10.Bit immer ein HIGH-Pegel ("Stoppbit") gesetzt wird. Dieses Verfahren funktioniert unabhängig von der aktuellen Baudrate, da die Verzögerungsglieder lediglich ein paar unkritische Vorher-Nachher-Bedingung gewährleisten müssen. Die Zeitglieder haben auch praktisch keinen nennenswerten Einfluss auf die tatsächliche Bitdauer der Start- und Stoppbits; diese wird ausschließlich durch das aus TXD gewonnene Zeitraster (IC3, Pin 11) bestimmt. Mehr als tausend Worte sagt hoffentlich das Timingdiagramm!

Das beschriebene Verfahren zur Erzeugung serieller Zeichen funktioniert optimal und fehlerfrei, wenn der Bitzähler mit dem Sendetakt "synchronisiert" wurde. Dann sind Start- und Stoppbits der zurückgelieferten Zeichen immer deckungsgleich mit den vom UART gesendeten Zeichen. In diesem Fall wird jedes über RXD zurückgelieferte Zeichen ein gültiges serielles Zeichen sein, es können keine "Framing-Errors" entstehen. Dann ist es auch vollkommen egal, wie unregelmäßig die Zeichen über TXD ausgegeben werden, da der UART selbstverständlich immer nur vollständige Zeichen sendet.
Dass die Start- und Stoppbits immer deckungsgleich sind, kann man bei Verwendung eines Zählers sicherstellen, wenn der Zähler zu Beginn der Übertragung einen entsprechenden RESET erhält. Genau genommen ist es hier ein "SET", denn der Zähler soll, wie auch im Timingdiagramm zu sehen, am Beginn der Übertragung auf "5" stehen.
Dieses Setzen des Zählers wird in der vorliegenden Schaltungsversion durch einen weiteren Optokoppler bewerkstelligt. Er wird durch die Schnittstellenleitung DTR gesteuert (Anschlussvariante 1, siehe weiter unten), und zwar so, dass der Set-Eingang des Zählers erst mit dem regulären Öffnen der Schnittstelle freigegeben wird. Auf diese Weise ist sichergestellt, dass der XR232 keinen Mucks von sich gibt, solange die Schnittstelle nicht regulär geöffnet ist, weil der Zähler zu diesem Zeitpunkt an seinem Set-Eingang dauerhaft HIGH ist - erst wenn die RS232-konforme Übertragung beginnt, wird der Zähler freigegeben, indem der Optokoppler den Set-Eingang auf LOW zieht. Jetzt steht der Zähler richtig und ist bereit, Taktimpulse zu zählen, sodass der XR232 bereits für das erste über TXD reinkommende Taktzeichen ein gültiges Zufallszeichen zurückliefert. Die zeitaufwändige Synchronisationsprozedur ist mit XR232-Schaltungsversion 2.x also nicht mehr notwendig.

Schnittstellen-Ankopplung

Die Verbindung zur computerseitigen RS232-Schnittstelle erfolgt aus den bereits genannten Gründen der Störsicherheit über Optokoppler.
Wegen der hohen Anforderungen an die Integrität der Signale wird mit echten bipolaren RS232-Pegeln gearbeitet, sodass für TXD und RXD je zwei Optokoppler benötigt werden. Es kommt eine abgewandelte Form meiner "Potenzialfreien Pegelwandlung für die RS232-Schnittstelle" [6] zum Einsatz.
Über einen weiteren Optokopper wird der Pegelwechsel auf der Statusleitung DTR (oder RTS) auf die Logikseite übernommen und sorgt dort für einen definierten Stand des Taktzählers, sobald die Schnittstelle geöffnet wird. Da man bei DTR (oder RTS) keine sehr schnellen Pegelwechsel auswerten muss, reicht für PC5 ein billiger Standard-Optokoppler (z.B. PC817).
Werden D7-D10 als Schottky-Dioden ausgeführt, gewinnt man insgesamt fast 1 Volt mehr Spannungshub für das zurückgelieferte RXD-Signal! Diese Maßnahme kann an einer schwachen RS232-Schnittstelle (Laptops) bereits den Unterschied zwischen "wackelig" und "geht immer" ausmachen.


Nach oben




Stückliste

Stückliste XR232 V2.1
---------------------

Kondensatoren

C1-C4         47nF
C5, C6        Elko 1000µF / 25V
C7, C8        100nF keramisch
C9, C10       1nF keramisch
C11,C12       100µF/25V


Widerstände (alle 1/4W 5%)

R1             330
R2-R7          2k2
R8,R9          4k7
R10,R11        220
R12            560
R13,R14        330
R15            4k7
R16            1k0


Halbleiter

VR1            7805
IC1            74LS00
IC2            74LS90
IC3            74LS74, 74HC74, 74HCT74

PC1-PC4        CNY17-II
PC5            PC817 / LTV817
D1-D4          SR120-160
D5-D10         BAT42
LED1           Farbe wurscht,
               "normal current"




Sonstiges

D-SUB-Buchse oder entsprechendes Anschlusskabel
(Brücken im Stecker, siehe Stromlaufplan)

6 x 1 mm-Lötstifte für Anschlussleisten X1/X2

Platine 53 x 100 mm nach Layout

Gehäuse z.B. TEKO-AL4, BOPLA-E430

Betriebsspannungsbuchse
(für Standard-Steckernetzteile 9 oder 12 V
meist Hohlstiftbuchse 2,1 oder 2,5 mm)

LED-Fassung


Rauschquelle Standardversion

XR1           4k7 (5%)
XR2           47k
XR3           100k
XC1,XC2       100nF (Folie, MKS)
XVT1,XVT2     BC547B/C
XZD           9V1 / 0.5W-Z-Diode


Abschirmbleche 20x33 mm und 20x20 mm
sowie 4 x 1 mm Lötstifte

Hinweis: XR232-Arbeitsblatt mit Bestückungsplan und weiteren Infos gibt's im Download.


Nach oben




Platinenlayout

Layout + Bestueckungsplan XR232 Version 2.0

Bild 5a/b:
Layout/Bestückungsplan zum XR232 V 2.x (200dpi).


Nach oben




Tipps zum Aufbau

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's 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 Papier muss der XR232-Schriftzug auf dem Bogen zunächst seitenverkehrt zu lesen sein. Die bedruckte Seite soll ja wie üblich direkt auf dem Kupfer bzw. der Fotoschicht aufliegen. Dort muss der Schriftzug nach dem Belichten und Entwickeln 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.
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!

Das aktuelle Paket XR232N.ZIP enthält jetzt auch ein PDF-Arbeitsblatt mit Bestückungsplan und Stückliste auf einer Seite.

RS232-Anschluss

Ein RS232-Kabel darf auch an der schwächsten seriellen Schnittstelle normalerweise noch mehrere Meter lang sein. Das gilt auch für XR232-Kabel. Gut geeignet sind normale Telefonschnüre mit vier Adern (lötbar, nicht dieser "Faserkram") oder auch ehemalige USB-Kabel.
Es muss kein geschirmtes Kabel sein. Falls 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 seinerseits keinen besonderen großen 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 doch  1-zu-1-Verlängerungskabel.)

Für den RS232-XR232-Stecker gibt es zwei mögliche Anschlussbelegungen, die praktisch gleichwertig sind, was die Funktionalität im Zusammenhang mit XR232 angeht. Es ist zweifelsohne die universellste Lösung, immer beide Brücken, also DTR-DSR und RTS-CTS vorzusehen. Mit diesem alten Trick deckt man praktisch alle Fälle ab, in denen ein Terminalprogramm oder ein sonstiger RS232-"DTE" (Data Terminal Equipment) mit einem Gerät kommunizieren will - Siehe untenstehenden Kasten zu den "Anschlussvarianten"!


Anschlussvariante 1

Gerät: D-SUB-Buchse (weiblich)
RXD (2) -- X2-d
TXD (3) -- X2-b
GND (5) -- X2-a
DTR (4) -- DSR (6)
RTS (7) -- CTS (8)
Abgriff X2-c an DTR-DSR
Schirm NUR im Stecker mit GND verbinden.

Die DTR-DSR-Brücke geht nach Öffnen der Schnittstelle permanent auf positiven Spannungspegel und liefert dem XR232 über Leitung X2-c eine Hilfsspannung für das Opto-Interface sowie Reset für den Bitzähler.

XR232 Anschlussvariante 1
Anschlussvariante 2

Gerät: D-SUB-Buchse (weiblich)
RXD (2) -- X2-d
TXD (3) -- X2-b
GND (5) -- X2-a
DTR (4) -- DSR (6)
RTS (7) -- CTS (8)
Abgriff X2-c an RTS-CTS
Schirm NUR im Stecker mit GND verbinden.

Die RTS-CTS-Brücke geht nach Öffnen der Schnittstelle ebenfalls dauerhaft auf positiven Spannungspegel und liefert dem XR232 über Leitung X2-c eine Hilfsspannung für das Opto-Interface sowie Reset für den Bitzähler.

XR232 Anschlussvariante 2

Gehäuse

Die optoelektronische Trennung verhindert sehr effektiv, dass man sich Störsignale über das RS232-Schnittstellenkabel einfängt und dass Potenzialunterschiede zwischen PC und XR232 Einfluss auf das Rauschsystem bekommen könnten. Vor direkter Hochfrequenzeinstrahlung schützt diese Maßnahme nur bedingt. Gegen elektrische und magnetische Wechselfelder hilft ein Vollmetallgehäuse. Dieses sichert die elektromagnetische Unabhängigkeit des Zufallsgenerators auch unter feindlichen Bedingungen (breitbandige Störstrahlung aus Computerkomponenten, Angriffe durch sogenanntes HF-Fluten).

Beim Einbau in ein HF-dichtes Metallgehäuse sollte Chassis auf direktem Weg mit Schaltungsmasse verbunden werden. Dafür ist der Erdungspin bei IC1/IC2 vorgesehen (siehe Bestückungsplan). Die Betriebsspannungsbuchse muss dann allerdings isoliert eingebaut werden, wenn man weiterhin die Option einer Wechselstromspeisung nutzen will.


Nach oben




Test

Elektrische Prüfungen:

Wenn o.k., dann:

... oder:

  • XR232 anschließen

  • Terminalprogramm, z.B. HyperTerminal mit folgenden Einstellungen starten:

    - Direktverbindung über COMx
    - Bits pro Sekunde: 9600
    - Datenbits: 8
    - Parität: Keine
    - Stoppbits 1 (1.5 und 2 gehen auch!)
    - Protokoll: Hardware

  • Manuell Taktzeichen senden (Shift-U)

  • Das sollte nach zahlreichen Tastendrücken etwa so aussehen:

    Beispiel Schirmdarstellung HyperTerminal


  • Auf jeden Tastendruck muss genau ein Zufallszeichen zurückkommen (wobei HT viele Zeichen nicht darstellen kann und leider auch keinen vernünftigen Hex-Modus anbietet. Eine Alternative wäre z.B. HTERM.)
    Wenn man beim Testen bemerkt, dass nicht auf jeden Tastendruck ein Zeichen zurückkommt -
    "Anruf - Trennen" und wieder "Anruf" - Dadurch wird der XR232-Bitzähler sicher resettet, die Übertragung sollte danach fehlerfrei funktionieren.



Nach oben



Software

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

  1. Port öffnen (DTR-DSR bzw. RTS-CTS gehen auf ca. +12V) -
    Sekunde warten, bis sich die Hilfsspannungen aufgebaut haben.

  2. n Taktzeichen senden

  3. Warten, bis n Zeichen im Empfangspuffer gelandet sind (bei Abweichung von n - Fehler! Weiter bei 7!)

  4. n Zufallszeichen abholen (und verarbeiten)

  5. Wenn weitere Zufallszeichen(blöcke) gewünscht, weiter bei 2, sonst:

  6. Port schließen (DTR-DSR und RTS-CTS gehen wieder auf -12V; der Bitzähler wird gesetzt und gesperrt) --- ENDE

  7. Fehlerbehandlung (auch bei allgemeinen Schnittstellenfehlern):
    Port schließen; Sekunde warten; zurück zu 1

Hinweis: Größere Sende- und Empfangspuffer werden in der Regel auf Treiberebene realisiert, denn 16550er-UARTs (und Kompatible) können nur 16 Bytes in ihrem Hardware-FIFO unterbringen. Die Emulation größerer FIFO-Puffer funktioniert je nach Betriebssystem/Compiler und anderen Umgebungsbedingungen (z.B. Interrupt-Nutzung) mehr oder weniger stabil. Die meisten Probleme beim XR232-Zugriff, die bisher auftraten, haben sich als Softwareprobleme herausgestellt.

Für Anwendungen, bei denen es auf Stabilität ankommt und nicht besonders viele Zufallszahlen benötigt werden, empfehle ich einen Zugriff in Einzelzeichen (also n=1). Hierbei entstehen allein durch die dazwischengeschalteten Treiber des Betriebssystems erhebliche Latenzzeiten in der Größenordnung  von mehreren Millisekunden, aber dafür ist jedes zurückgelieferte Zeichen mit großer Sicherheit ein echtes Zufallszeichen. Wer es noch sicherer haben will, kann zwischendurch auch noch die Schnittstelle immer wieder schließen und öffnen, um eine Reinitialisierung des Bitzählers zu erzwingen. Die Wartezeit zum Aufladen der Elkos entfällt hierbei.

Wenn größere Zufallsdatenmengen erzeugt werden müssen, möchte man natürlich die eingestellte Baudrate effektiv nutzen. Hier wirkt ein Zugriff in kleinen Datenblöcken wahre Wunder. Bereits mit Blockgrößen von 16 oder 64 Zeichen lässt sich die Performance der Schnittstelle deutlich steigern. Innerhalb der Blöcke kommt es zu keinen zeitlichen Unterbrechungen mehr. Bei diesem blockweisen Zugriff muss man programmtechnisch einfach nur abwarten, bis ebensoviele Zeichen zurückgeliefert wurden, wie man zuvor gesendet hat. Nebenbei lässt sich damit prüfen, ob Übertragungsfehler oder Taktfehler aufgetreten sind. Dynamische Zugriffe, bei denen der FIFO-Puffer immer nur nachgefüllt wird, sind möglich und wahrscheinlich noch effektiver (siehe [9]).

Meinerseits stelle ich ein paar Demoprogramme (Punkt [11] der Linkliste) in QBasic sowie das DOS-Kommandozeilentool XR232.EXE zur Verfügung. Das DOS-Tool ermöglicht die wichtigsten Funktionstests des XR232 wie auch das Erzeugen größerer Zufallsdateien unter Anwendung verschiedener Balancierungsoptionen. Das Tool läuft nachweislich unter DRDOS, Open-DOS, MSDOS (ab Version 4.0) sowie in einem Fenster unter Win9x.

WICHTIGER HINWEIS: Das DOS-Tool wird von mir nicht mehr weiterentwickelt. Bitte beachten Sie mein Konsolentool aus dem Nachfolgeprojekt XR232USB, welches ab WinNT sowie und aktuellen Linuxen lauffähig ist und insbesondere auch mit virtuellen seriellen Ports (USB-COM-Wandler) klarkommt!



Nach oben


Anmerkungen

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 Hardwarekomponenten, die vorgeben, speziell für Kryptoanwendungen eigene Zufallsgeneratoren vorzuhalten, ist sicher ein verstärktes Misstrauen angebracht. Vor allem, wenn die jeweilige "Lösung" nicht in allen technischen Details lückenlos offengelegt ist! So haben einige neuzeitliche CPUs angeblich einen "echten Zufallsgenerator" on-chip [4]. Wäre das nicht eine superelegante Methode zur Generierung von Zufallszahlen für allerlei sicherheitsrelevante (kryptografische) Anwendungen? Ja, das wäre es, aber nur, wenn man den Pressemitteilungen blind vertraut und einfach mal sämtliche physikalischen Gesetzmäßigkeiten außer Acht lässt. Wer dem Glaubensprinzip nicht so zugetan ist, der wundert sich schon allein über die Behauptung, dass diese P**lock Engine auf einer elektronischen Zufallsquelle beruhe, welche das thermische Rauschen ausnutze. Wohlgemerkt, dieser imaginäre Zufallsgenerator befindet sich direkt auf der CPU, und es wird ausdrücklich von einer elektronischen Rauschquelle gesprochen. Dennoch soll diese Zufallsquelle vollkommen unabhängig arbeiten. In direkter Nachbarschaft zu hochfrequenten und höchstfrequenten Taktsignalen... Also, ich finde ja, wenn sie von einer quantenoptischen Rauschquelle gesprochen hätten, dann wäre die Legende wenigstens ein Stück weit glaubwürdiger, aber soooo? Wenn das Teil in allen Tests so perfekte und scheinbar unabhängige Zufallszahlen produziert, dann liegt der Verdacht nahe, dass es sich in Wirklichkeit um einen komplexen Pseudozufallsgenerator handelt. Nur Pseudozufallsgeneratoren können so designt werden, dass sie bestimmte Testverfahren bestehen. Eine solche Implementierung, deren Details nicht einmal offengelegt sind, hat keine "Hintertürchen" - sie IST ein einziges Hintertürchen und somit für ernsthafte Anwendungen vollkommen indiskutabel.

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 nichtsahnend auf ein unvollständig ausgestattetes Board ohne RS232-Ports hereingefallen ist, gibt es immernoch die Alternative einer sündhaft teuren PCI-Erweiterungskarte - oder eines sogenannten USB-RS232-Adapters. Dafür braucht's dann wieder spezielle Treiber, aber das Problem der Weiterverwendung von RS232-Geräten auf sogenannten modernen Computern wäre damit im Grunde schon gelöst.
Nach meinen Erfahrungen halten sich selbst billige USB-Seriell-Adapter für EUR 9.95 überraschend gut an die Spezifikationen, zumindest was das Timing der Signale und die Nutzung der Handshake-Leitungen angeht.
Sofern man ein echtes RS232-Gerät über so einen Adapter anschließen will, dürfte es eigentlich keine Probleme geben. Der XR232 arbeitet problemlos mit solchen Adaptern zusammen, obwohl die Schnittstellenspannungen hier oft nur +/- 5V statt +/- 12V betragen. (Hauptsache bipolar!)

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, einem transparenten Protokoll und preiswerten Standardkomponenten beruht.

Der XR232 liefert in der jetzigen, bestens abgehangenen Schaltungsversion vorbalancierte Zufallsdaten mit bis zu 57600 Baud an die serielle Schnittstelle.

Alleinstellungsmerkmale sind die robuste, transparente Technik und die Tatsache, dass Ansteuerung und Datenübertragung dieses Zufallsgenerators konsequent nach RS232-Standard erfolgen. Die Nutzung eines XR232 ist prinzipiell auf jeder Rechnerplattform möglich, die eine halbwegs normgerechte RS232-Schnittstelle mit Handshake-Leitungen bereitstellt. Wenn die bevorzugte Programmierumgebung normale Datenzugriffe auf RS232-Schnittstellen erlaubt, dann ist auch eine Nutzung des XR232 auf diesem Weg möglich.

Inzwischen steht eine Reihe von Programmierbeispielen für DOS/Windows/Linux zur Verfügung. Diese Projekte sind zumeist quelloffen über die URLs der jeweiligen Autoren verfügbar. Bitte haben Sie Verständnis, dass ich selbst mich vor allem auf die Hardwareseite konzentriere!

Wer 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 stelle ich zum Selbstkostenpreis zur Verfügung. Bei Interesse bitte mailen!


Nach oben




Links

[1] Prinzipien zu Rauschquellen, Breitbandverstä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 auf einmal:
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 (Vorgängerprojekt "RAND232")

[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 FA-Download-Archiv, Stichwort "XR232": www.funkamateur.de

[9] Linuxprojekt für den XR232 von Meinhard Schneider: http://xr232.dl1fms.de/

[10] XR232-Gerätetreiber - Projekt "xr232random" von Jochen Brenner: http://xr232.noedit.de

[11] Julien's Paket aus XR232-Schaltunterlagen und DOS-Tool
WICHTIGER HINWEIS: Die EXE wird nicht mehr weiterentwickelt. Bitte beachten Sie mein leistungsfähigeres Konsolentool zum Nachfolgeprojekt XR232USB, welches mit XR232 kompatibel ist und für DOS, Win32 und Linux zur Verfügung steht!

[12] XR232-Konsolenprogramme und Weiterentwicklungen (vorw. Linux): http://herzer-online.dyndns.org/xr232

[13] Hartmuth Krüger's XR232-Demoprogramme mit GUI für Windows: https://4hardy.de/homepage/


Nach oben

Index

Revisionen: 02/2007 - 05/2009 - 06/2009 - 08/2011 - 02/2015