FAQFAQ SuchenSuchen MitgliederlisteMitgliederliste BenutzergruppenBenutzergruppen  RegistrierenRegistrieren  ProfilProfil Einloggen, um private Nachrichten zu lesenP.M. LoginLogin
Sichere Funkübertragung, z.B. zu Zündgeräten
Gehe zu Seite Zurück  1, 2, 3
 
Neues Thema eröffnen   Neue Antwort erstellen    EURocketry Foren-Übersicht -> Zubehoer
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  

Autor Nachricht
Juerg
Site Admin


Anmeldungsdatum: 27.02.2005
Beiträge: 4545
Wohnort: Oberengstringen

BeitragVerfasst am: Sa 24 Dez 2005, 11:29    Titel: Antworten mit Zitat

Ah, ok, falsch verstanden.
Das Problem bleibt aber ungelöst, wenn Du grosse Datenströme übertragen willst, wie z.B. bei der Ariane zwischen Bordrechner und Bodenstation. Dort flossen z.B. dauernd Nutzdaten, so dass kein Raum für eingefügte 0x55 bleibt.
In diesem Fall kommst Du um eine Modifikation des Datenstromes nicht herum, und Manchester bietet sich als relativ einfach zu implementierende Lösung an, allerdings um den Preis halbierter Bandbreite. Dafür ist die Modulion/Demodulation extrem einfach.
Aber EFM garantiert doch nicht die benötigte DC-Freiheit von mark/space ratio besser als 20/80%?

_________________
http://www.SpacetecRocketry.com
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Andreas Müller



Anmeldungsdatum: 28.02.2005
Beiträge: 2493
Wohnort: Altendorf

BeitragVerfasst am: Sa 24 Dez 2005, 20:45    Titel: Antworten mit Zitat

Juerg hat folgendes geschrieben:

Das Problem bleibt aber ungelöst, wenn Du grosse Datenströme übertragen willst, wie z.B. bei der Ariane zwischen Bordrechner und Bodenstation. Dort flossen z.B. dauernd Nutzdaten, so dass kein Raum für eingefügte 0x55 bleibt.

Doch, wenn die Daten verschlüsselt sind, brauchst Du nicht mal die 0x55, weil die Daten selbst schon 50/50 sind. Ein verschlüsselter Datenstrom ist DC-frei. Er mag andere Eigenschaften haben, die für die Funkübermittlung nicht zweckmässig sind, zum Beispiel, dass die grösste Run length 9 Bitzeiten ist, aber duty cycle ist definitiv nicht das Problem.

Klar, für die Übermittlung der Daten der Ariane zum Boden wäre Verschlüsselung nicht unbedingt sinnvoll (oder habt ihr etwas zu verbergen?), da ist es sinnvoller Manchester oder EFM zu verwenden. Der Vorteil von EFM besteht darin, dass die Run-Length besser verteilt sind, so dass man mit höherer Rate übertragen kann, und so im Endeffekt eventuell sogar eine bessere Ausnutzung des Kanales erreicht. Dies hat man mit EFM+ bei der DVD geschafft, der Kapazitätsgewinn macht dabei etwa 7% aus.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Juerg
Site Admin


Anmeldungsdatum: 27.02.2005
Beiträge: 4545
Wohnort: Oberengstringen

BeitragVerfasst am: Mo 26 Dez 2005, 0:07    Titel: Antworten mit Zitat

Wenn mich nicht alles täuscht ist bei EFM die maximale Anzahl Nullen zwischen zwei benachbarten Einsen in der Grössenordnung von 10, also weit ab von 80/20!
Ich habe von Verschlüsselung zu wenig Ahnung, aber warum soll der Datenstrom vollständig DC-Frei sein?
Das würde nämlich bedeuten, dass Du genau gleichviele 1 wie 0 hast.
Rein zufällig kann sowas nicht entstehen. Der kleine Exkurs in Verschlüsselung dürfte sich lohnen.

Gruss

Jürg

_________________
http://www.SpacetecRocketry.com
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Andreas Müller



Anmeldungsdatum: 28.02.2005
Beiträge: 2493
Wohnort: Altendorf

BeitragVerfasst am: Mo 26 Dez 2005, 14:09    Titel: Antworten mit Zitat

Juerg hat folgendes geschrieben:
Wenn mich nicht alles täuscht ist bei EFM die maximale Anzahl Nullen zwischen zwei benachbarten Einsen in der Grössenordnung von 10, also weit ab von 80/20!

EFM und EFM+ sind DC frei. Der Witz bei beiden ist, dass eben nicht nur der Abstand zwischen Einsen gross ist, sondern auch der Abstand zwischen Nullen. Damit wird es immer noch möglich, DC-freiheit zu erreichen. Besonders wichtig ist aber, dass nur ein Teil des Spektrums bis zur Bitrate ausgenützt wird, d.h. man kann den gleichen Kanal, d.h. die gleiche Bandbreite, mit höherer Bitrate ausnützen, so dass im Endeffekt mehr Bits pro Sekunde durch den Kanal gehen. Den EFM kann man zum Beispiel im gleichen Kanal mit doppelter Bitrate betreiben, d.h. um 8 bit zu übertragen, braucht man nur 14 neue Bitzeiten, d.h. 7 alte. Man gewinnt also 14% Bandbreite.

Selbstverständlich ist das noch immer ein ganz lausige Ausnützung des zur Verfügung stehenden Spektrums, weil nur zwei Zustände (1 und 0) im Kanal zugelassen sind. Dass man damit nicht weit kommt, haben die Modems in den letzten 20 Jahren bewiesen. Auch 14400er Modems arbeiten mit einer Baudrate von 2400, da die Anzahl der Zustände des Kanales aber stark vergrössert wurde, lässt sich die grosse Bitrate realisieren. Ausserdem verteilt sich dabei die Energie gleichmässiger über das zur Verfügung stehende Spektrum, nicht wie bei binärer Codierung, wo die ganze Energie in wenigen Frequenzen konzentriert ist.

Zitat:
Ich habe von Verschlüsselung zu wenig Ahnung, aber warum soll der Datenstrom vollständig DC-Frei sein?
Das würde nämlich bedeuten, dass Du genau gleichviele 1 wie 0 hast.

Ein guter Verschlüssler hat unter anderem die folgende statistische Eigenschaft: wenn ich im Klartext ein Bit kehre, wechseln im Schnitt 50% der Bits im Chiffrat. Wenn ich also dafür sorge, dass in jedem übermittelten Block mindestens ein Bit ändert, kann ich statistisch davon ausgehen, dass in jedem Chiffratblock 50% der Bits ändern. Selbst wenn ich mal auf 0x00 treffen sollte, kann ich beim nächsten Block wieder 50/50 erwarten.

Eine weitere Eigenschaft guter Verschlüssler (und DES gehört dazu) ist, dass bei einigermassen variablem Input im Chiffrat alle Bytes gleich wahrscheinlich sind. Durch den vorgeschlagenen Seriennummer-Zähler und den Hash ist sichergestellt, dass pro Block ca 9bits ändern, d.h. man hat einiges an Variabilität. Somit kann man davon ausgehen, dass im Chiffrat jedes Byte gleich wahrscheinlich ist. Folglich sind ca 50% der Bits Einsen.

Dies müsste man natürlich beweisen, aber das ist nicht so schwierig. Was interessiert ist der Erwartungswert der Anzahl Einsen, als E[#1]. Nun kann ich durch Komplementbildung jedes Byte mit x Einsen ein solches mit x Nullen abbilden. Dabei werden Bytes eineindeutig zugeordnet, d.h. E[#1] = E[#0]. Ausserdem ist #0 = 8 - #1 in einem Byte, d.h. E[#0] = E[8 - #1] = 8 - E[#1]. Damit bekommt man die Gleichung

E[#1] = 8 - E[#1]

oder E[#1] = 4, d.h. wir dürfen erwarten, dass die Hälfte der Bits eines Byte Einsen sind. QED.

Zitat:
Rein zufällig kann sowas nicht entstehen. Der kleine Exkurs in Verschlüsselung dürfte sich lohnen.

Im Gegenteil, rein zufällig entsteht genau das Smile

Dies ist natürlich eine statistische Aussage, d.h. kurzfristig, über einige wenige Bytes, kann sich ein Ungleichgewicht einstellen, im Mittel über grössere Blöcke aber darf ich 50% annehmen. Unter der Voraussetzung natürlich, dass der Klartext variabel ist, sonst gibt es keine Statistik. Das vorgeschlagene Protokoll erfüllt diese Bedingung allerdings bereits.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Juerg
Site Admin


Anmeldungsdatum: 27.02.2005
Beiträge: 4545
Wohnort: Oberengstringen

BeitragVerfasst am: Mo 26 Dez 2005, 15:13    Titel: Antworten mit Zitat

Mmm, ich bin nicht vollständig überzeugt, dass die 50/50 Rate im kurzzeitigen Mittel (einige wenige Bytes) wirklich immer erfüllt ist. Statistisch mag es stimmen. Ich muss mich mal etwas in die Materie eingraben.

Danke für die Erläuterung!

_________________
http://www.SpacetecRocketry.com
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Andreas Müller



Anmeldungsdatum: 28.02.2005
Beiträge: 2493
Wohnort: Altendorf

BeitragVerfasst am: Mo 26 Dez 2005, 23:08    Titel: Antworten mit Zitat

Juerg hat folgendes geschrieben:
Mmm, ich bin nicht vollständig überzeugt, dass die 50/50 Rate im kurzzeitigen Mittel (einige wenige Bytes) wirklich immer erfüllt ist. Statistisch mag es stimmen.

Ok, hier sind ein paar Zahlen dazu. Das angehängte kleine C-Programm mit Makefile kompiliert auf Unix mit openssl (ein binary für SuSE 9.3 ist im Archiv ebenfalls enthalten) und kann dazu verwendet werden, Statistik zu den genannten Grössen zu machen. Es produziert aus einer Folge von Ganzzahlen jeweils einen 8 Byte Block bestehend aus zwei Kopien der Ganzzahl. Dieser Block wird anschliessen DES-verschlüsselt, und die Anzahl der Bits darin gezählt. Für die ersten fünf Millionen Zahlen und einen zufälligen DES Schlüssel ergibt sich folgendes:

1. Wie erwartet ist der Erwartungswert der Anzahl der Einsen 32
2. mehr als 20bit neben dem Mittelwert kommt gar nicht vor (Wahrscheinlichkeit 0)
3. Die Wahrscheinlichkeit, besser als 40/60 zu sein ist 90%.

Selbst für wenige Bytes ist also die Statistik erstaunlich gut. Natürlich nicht so gut wie EMF oder EMF+, aber für kurze Übertragungen wohl ausreichend. Und für längere Übertragungen ist diese Statistik nicht direkt anwendbar. Allerdings ist der Einzelblock eigentlich der ungünstigste Fall, sobald mehr Blocks zusammenkommen, verschiebt sich die Statistik hin zu einem ausgewogeneren 0/1-Verhältnis.

Hier die Resultate im Detail:

Code:
afm@gurin:~/Projects/cryptostat> ./cryptostat -v -l 6 -b 0 -e 5000000

Erwartungswert für die Anzahl der Einsen:
Code:
E[#1] =  32.00404480

Wahrscheinlichkeit, dass die Anzahl der Einsen höchstens um 6 vom Erwartungswert abweicht:
Code:
P[|#1 - 32| <= 6] =   0.89658900

Wahscheinlichkeitsverteilung für die verschiedenen Anzahlen von Einsen:
Code:
P[#1=  0] =   0.00000000
P[#1=  1] =   0.00000000
P[#1=  2] =   0.00000000
P[#1=  3] =   0.00000000
P[#1=  4] =   0.00000000
P[#1=  5] =   0.00000000
P[#1=  6] =   0.00000000
P[#1=  7] =   0.00000000
P[#1=  8] =   0.00000000
P[#1=  9] =   0.00000000
P[#1= 10] =   0.00000000
P[#1= 11] =   0.00000000
P[#1= 12] =   0.00000000
P[#1= 13] =   0.00000160
P[#1= 14] =   0.00000120
P[#1= 15] =   0.00000880
P[#1= 16] =   0.00002580
P[#1= 17] =   0.00007520
P[#1= 18] =   0.00019120
P[#1= 19] =   0.00045960
P[#1= 20] =   0.00105360
P[#1= 21] =   0.00223140
P[#1= 22] =   0.00439420
P[#1= 23] =   0.00790460
P[#1= 24] =   0.01365820
P[#1= 25] =   0.02179600
P[#1= 26] =   0.03267620
P[#1= 27] =   0.04596560
P[#1= 28] =   0.06066440
P[#1= 29] =   0.07508920
P[#1= 30] =   0.08778940
P[#1= 31] =   0.09622320
P[#1= 32] =   0.09928600
P[#1= 33] =   0.09627700
P[#1= 34] =   0.08787120
P[#1= 35] =   0.07540840
P[#1= 36] =   0.06072780
P[#1= 37] =   0.04593700
P[#1= 38] =   0.03267880
P[#1= 39] =   0.02172400
P[#1= 40] =   0.01356420
P[#1= 41] =   0.00792160
P[#1= 42] =   0.00435980
P[#1= 43] =   0.00222240
P[#1= 44] =   0.00104520
P[#1= 45] =   0.00044600
P[#1= 46] =   0.00020220
P[#1= 47] =   0.00007900
P[#1= 48] =   0.00002820
P[#1= 49] =   0.00000920
P[#1= 50] =   0.00000220
P[#1= 51] =   0.00000040
P[#1= 52] =   0.00000000
P[#1= 53] =   0.00000000
P[#1= 54] =   0.00000000
P[#1= 55] =   0.00000000
P[#1= 56] =   0.00000000
P[#1= 57] =   0.00000000
P[#1= 58] =   0.00000000
P[#1= 59] =   0.00000000
P[#1= 60] =   0.00000000
P[#1= 61] =   0.00000000
P[#1= 62] =   0.00000000
P[#1= 63] =   0.00000000
P[#1= 64] =   0.00000000



cryptostat.zip
 Beschreibung:
ZIP Archiv mit Programm und Makefile für DES Bit Statistik

Download
 Dateiname:  cryptostat.zip
 Dateigröße:  6.88 KB
 Heruntergeladen:  354 mal

Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    EURocketry Foren-Übersicht -> Zubehoer Alle Zeiten sind GMT + 2 Stunden
Gehe zu Seite Zurück  1, 2, 3
Seite 3 von 3
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten
Du kannst Dateien in diesem Forum herunterladen

Powered by phpBB © 2001, 2002 phpBB Group
mtechnik