One-time-pad-Crypter

Code-Stücke können hier veröffentlicht werden.
murph
User
Beiträge: 622
Registriert: Freitag 14. April 2006, 19:23
Kontaktdaten:

Donnerstag 25. Mai 2006, 22:16

dann hast du unsauber gelesen! Jedes mal wird ein neues Passwort vom System entworfen, auch wenn ich diese abspeicher, ist sie jedes mal neu, wenn ich was verschlüssele... ;)

Aber der Punkt, dass beide Seiten gleiche Zufallszahlen ermitteln und dann abgleichen und danach "wegwerfen", ist ja schon sehr schwer, also, wieviel Zufall ist das denn, wenn m´beide Seiten das gleiche ermitteln, ohne abzugleichen?
Python 47
User
Beiträge: 574
Registriert: Samstag 17. September 2005, 21:04

Freitag 26. Mai 2006, 00:11

murph hat geschrieben:dann hast du unsauber gelesen! Jedes mal wird ein neues Passwort vom System entworfen, auch wenn ich diese abspeicher, ist sie jedes mal neu, wenn ich was verschlüssele... ;)
Dann würde ich dir mal empfehlen genauer zu lesen :lol:
BlackJack hat geschrieben: Bei echtem One-Time-Pad braucht man keine Passwörter sondern nur die gleichen Zufallsdaten auf beiden Seiten.
mfg

Thomas :-)
BlackJack

Freitag 26. Mai 2006, 07:32

murph hat geschrieben: Aber der Punkt, dass beide Seiten gleiche Zufallszahlen ermitteln und dann abgleichen und danach "wegwerfen", ist ja schon sehr schwer, also, wieviel Zufall ist das denn, wenn m´beide Seiten das gleiche ermitteln, ohne abzugleichen?
Es werden nicht auf beiden Seiten gleiche Zufallszahlen ermittelt. Wenn man das könnte dann sind die Zahlen ja nicht mehr zufällig, sondern berechenbar. :roll:

One-Time-Pad funktioniert so, dass eine Seite sehr viele Zufallsbytes erzeugt, und zwar "wirklich" zufällige und nicht einfach berechenbare. Diese Daten müssen dann auf sicherem Weg an den Empfänger übermittelt werden. Zum Beispiel per vertrauenswürdigem Kurier auf CD oder DVD oder am besten eine persönliche Übergabe. Jetzt kann der Sender zum Beispiel eine 1000 Bytes lange Nachricht mit den ersten 1000 Zufallsbytes verschlüsseln und übertragen. Der Empfänger nimmt dann die ersten 1000 Zufallsbytes von seiner Kopie zum entschlüsseln. Danach werden die ersten 1000 Bytes "weggeworfen", d.h. nie wieder zum verschlüsseln verwendet. Wenn die Zufallsdaten "aufgebraucht" sind, dann muss man neue austauschen.

Bei der Nachrichtenübertragung braucht man dann keinen Schlüssel mehr. Und so eine Nachricht ist wirklich unknackbar weil der Klartext aus Sicht eines Angreifers im Grunde jede mögliche Kombination von 1000 Bytes sein kann. Jede ist gleich wahrscheinlich.
murph
User
Beiträge: 622
Registriert: Freitag 14. April 2006, 19:23
Kontaktdaten:

Freitag 26. Mai 2006, 10:17

aber ist dann "a.501" nicht ausreichend? die datei wird vertrauenswürdig überliefert und danach vom rechner am besten gelöscht,
bei der nächsten Datei werden dann neue Zufallszahlen ermittelt.
Zwar ist selbst systemrandom oder urandom nicht hundertprozentiger unnachvollziehbar, aber radioaktives material möchte ich auch nich gerne in meinem zimmer haben, in dem ich lebe ;)
BlackJack

Freitag 26. Mai 2006, 22:43

murph hat geschrieben:aber ist dann "a.501" nicht ausreichend? die datei wird vertrauenswürdig überliefert und danach vom rechner am besten gelöscht,
bei der nächsten Datei werden dann neue Zufallszahlen ermittelt.
Das heisst Du müsstest für jede Nachricht die gleiche Menge an Zufallsdaten in der "a.501" auf einem sowieso schon sicheren Weg übermitteln. Dann kannst Du doch über diesen Kanal gleich die eigentliche Nachricht übermitteln und die Verschlüsselung sparen. Und wozu brauchst Du das zusätzliche Passwort?
murph
User
Beiträge: 622
Registriert: Freitag 14. April 2006, 19:23
Kontaktdaten:

Samstag 27. Mai 2006, 16:42

doppelt hält besser^^
ich dachte mir, dass man "a.501" auch auf einem unsicherem wege übermitteln kann, da es schwer zu knacken ist, weil das ergebnis ja unkenntlich ist, sprich: der, der das versucht zu encrypten, wird als ergebnis jede menge sch***e erhalten. Das soll das ganze noch ein wenig erschweren, wenn man dann schonmal die datei "a.501" hat.
Python 47
User
Beiträge: 574
Registriert: Samstag 17. September 2005, 21:04

Samstag 27. Mai 2006, 18:05

murph hat geschrieben:doppelt hält besser^^
ich dachte mir, dass man "a.501" auch auf einem unsicherem wege übermitteln kann, da es schwer zu knacken ist, weil das ergebnis ja unkenntlich ist, sprich: der, der das versucht zu encrypten, wird als ergebnis jede menge sch***e erhalten. Das soll das ganze noch ein wenig erschweren, wenn man dann schonmal die datei "a.501" hat.
Dann ist es aber trotzdem kein One Time Pad, denn ein One Time Pad zeichnet sich aus, das es mathematisch absolut unknackbar ist. Und das wäre es nicht mehr, wenn jem. die Datei in die Finger bekommt. :D
mfg

Thomas :-)
murph
User
Beiträge: 622
Registriert: Freitag 14. April 2006, 19:23
Kontaktdaten:

Samstag 27. Mai 2006, 18:41

du weißt, dass du dir selbst widersprichst? wenn etwas mathematisch unknackbar ist, du aber die Lösung hast, ist es immer noch mathematisch unknackbar, aber es is trotzdem machbar, an den inhalt zu kommen!!!
Python 47
User
Beiträge: 574
Registriert: Samstag 17. September 2005, 21:04

Samstag 27. Mai 2006, 19:18

murph hat geschrieben:du weißt, dass du dir selbst widersprichst? wenn etwas mathematisch unknackbar ist, du aber die Lösung hast, ist es immer noch mathematisch unknackbar, aber es is trotzdem machbar, an den inhalt zu kommen!!!
Da wiedersprichst du dich ein bischen. Wenn ich die Lösung habe, sprich ich habe es entschlüsselt, dann ist die Verschlüsselung nicht länger unknackbar. Wie dem auch sei, trotzdem ist es kein One Time Pad, so wie du das machst.

Gruß Thomas :wink:
mfg

Thomas :-)
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Samstag 27. Mai 2006, 19:57

geht sterben -.-
TUFKAB – the user formerly known as blackbird
murph
User
Beiträge: 622
Registriert: Freitag 14. April 2006, 19:23
Kontaktdaten:

Samstag 27. Mai 2006, 20:31

du hast ungenau gelesen: wenn man eine lösung hat, heißt das nicht, dass man die sich erhackt hat!

die betonung lag auf _mathematisch_. Nochmal lesen und glücklich sein ;)
BlackJack

Sonntag 28. Mai 2006, 23:20

murph hat geschrieben:ich dachte mir, dass man "a.501" auch auf einem unsicherem wege übermitteln kann, da es schwer zu knacken ist, weil das ergebnis ja unkenntlich ist, sprich: der, der das versucht zu encrypten, wird als ergebnis jede menge sch***e erhalten. Das soll das ganze noch ein wenig erschweren, wenn man dann schonmal die datei "a.501" hat.
Wenn man die "a.501" hat, dann hängt es nur noch am Passwort. Wie Python Master schrieb: One Time Pad ist unknackbar wenn man die Pad-Daten nicht in die Finger bekommt. Die müssen auf einem sicheren Weg übertragen werden. Sonst ist das ganze einfach kein One-Time-Pad mehr.

One-Time-Pad sieht so aus:

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: utf-8 -*-
"""One Time Pad."""
from __future__ import division
import os
import sys
from itertools import izip
from mmap import mmap, ACCESS_READ
from optparse import OptionParser

__author__ = "Marc 'BlackJack' Rintsch"
__version__ = '0.0.1'
__date__ = '$Date: 2006-05-27 22:08:57 +0200 (Sat, 27 May 2006) $'
__revision__ = '$Rev: 857 $'


BLOCK_SIZE = 1024 * 1024    # 1 Mib


def write_random_bytes(count, fileobj, block_size=BLOCK_SIZE):
    """Write cryptographically secure random data."""
    while count > 0:
        fileobj.write(os.urandom(min(block_size, count)))
        count -= block_size


def crypt(in_data, out_file, pad_data):
    """Encrypt `in_data` with `pad_data` and write to `out_file`."""
    for in_byte, pad_byte in izip(in_data, pad_data):
        out_file.write(chr(ord(in_byte) ^ ord(pad_byte)))


def crypt_file(in_name, out_name, pad_name, offset):
    """Encrypt a file.
    
    The three names are paths to the file to be processed, the file where the
    processed data should be written to and the file with the one time pad data.
    
    Additionally the `offset` into the one time pad file has to be given.  The
    return value is the `offset` plus the length of the processed data.
    
    The function maps the unencrypted file and the one time pad data into
    memory so both together must fit into virtual memory.
    """
    size = os.path.getsize(in_name)
    pad_size = os.path.getsize(pad_name)
    in_file = open(in_name, 'rb')
    out_file = open(out_name, 'wb')
    pad_file = open(pad_name, 'rb')
    in_data = mmap(in_file.fileno(), size, access=ACCESS_READ)
    pad_data = buffer(mmap(pad_file.fileno(), pad_size, access=ACCESS_READ),
                      offset)
    crypt(in_data, out_file, pad_data)
    for fileobj in (in_file, out_file, pad_file):
        fileobj.close()
    return size + offset


def cmd_generate_pad(options, args):
    """Implements the one time pad generation command."""
    if len(args) == 0:
        out_file = sys.stdout
    else:
        out_file = open(args[0], 'wb')
    write_random_bytes(options.pad_size * 1000000, out_file)


def cmd_crypt(options, args):
    """Implements the crypt command."""
    if len(args) != 3:
        sys.exit('need in-, out- and pad-filename')
    offset = options.offset
    print crypt_file(args[0], args[1], args[2], offset)


def main():
    """Main function."""
    usage = '%prog [options] command'
    parser = OptionParser(usage=usage, version=__version__)
    parser.add_option('-s', '--pad-size', type='int', default=1,
                      metavar='SIZE',
                      help='generate pad data with SIZE MB (%default)')
    parser.add_option('-o', '--offset', type='int', default=0,
                      help='offset into one time pad data')
    
    commands = { 'generate': cmd_generate_pad,
                 'crypt': cmd_crypt }

    (options, args) = parser.parse_args()
    
    if len(args) == 0:
        parser.error('Need at least one command %r' % commands.keys())
    
    try:
        command = commands[args[0]]
    except KeyError:
        parser.error('Unknown command %r' % args[0])
    
    command(options, args[1:])


if __name__ == '__main__':
    main()
Das Programm kann One-Time-Pad Zufallsdaten erzeugen und ver- und entschlüsseln. Zwischen ver- und entschlüsseln gibt's eigentlich keinen Unterschied, da beide Operationen symmetrisch sind. Liegt in der Natur der XOR-Operation.

Nehmen wir einmal an, Alice möchte Bob Nachrichten schicken. Als erstes müssen Zufallsdaten erzeugt werden. Alice nennt diese Datei bob.pad, damit sie weiss, dass sie diese Datei zum Verschlüsseln von Nachrichten an Bob verwenden muss.

Code: Alles auswählen

alice> onetimepad.py generate --pad-size 650 bob.pad
Damit werden 650MB Zufallsdaten erzeugt. Das sollte eine Weile reichen. Diese Daten brennt Alice auf eine CD und übergibt Bob diese bei einem persönlichen Treffen.

Dann kann Alice eine Nachricht verschlüssen:

Code: Alles auswählen

alice> onetimepad.py crypt --offset 0 klartext.txt verschluesselt-0.msg bob.pad
42
Damit wird die Datei klartext.txt verschlüsselt. Der Offset in die Zufallsdaten ist 0, da dies die erste Nachricht ist. Das Programm gibt den Offset plus die Länge der Nachricht wieder aus. Diese Zahl kann als Offset für die nächste Verschlüsselung benutzt werden. Das ist wichtig, damit niemals die gleichen Zufallsdaten zum Verschlüsseln benutzt werden. Die nächste Nachricht würde Alice wie folgt verschlüssen:

Code: Alles auswählen

alice> onetimepad.py crypt --offset 42 nachtrag.txt verschluesselt-42.msg bob.pad
656
Wie man sieht schreibt Alice den Offset auch noch einmal in den Dateinamen der verschlüsselten Nachricht, damit weiss Bob mit welchem Offset er die Datei wieder entschlüsseln muss. Den Nachtrag entschlüsselt Bob also so:

Code: Alles auswählen

bob> onetimepad.py crypt --offset 42 verschluesselt-42.msg von_alice.txt  bob.pad
656
Das Programm hat einige Unzulänglichkeiten. Man muss sich für's Verschlüsseln die Offsets merken, es gibt keine Fehlerbehandlung und ich war zu faul ordentlichen Code für das Dateihandling zu schreiben. Deshalb werden die Eingabedatei und die Pad-Datei mit mmap.mmap() in den virtuellen Speicher abgebildet. Diese beiden Dateien zusammen dürfen folglich nicht grösser sein, als der virtuelle Speicher der einem Prozess zur Verfügung steht und einzeln nicht grösser als 2GB.

Aber es ist ja auch nur als einfaches Beispiel gedacht. Auf jeden Fall kann kein Angreifer eine abgefangene verschlüsselte Nachricht knacken. Die kann man ansonsten völlig ungesichert übertragen, die sind mathematisch unknackbar. Sogar wenn der Angreifer eine Plaintext Nachricht kennt oder sogar selber erzeugen darf, erlaubt ihm die verschlüsselte Nachricht keine Rückschlüsse auf den Inhalt folgender Nachrichten.
Python 47
User
Beiträge: 574
Registriert: Samstag 17. September 2005, 21:04

Montag 29. Mai 2006, 22:09

BlackJack hat geschrieben:Auf jeden Fall kann kein Angreifer eine abgefangene verschlüsselte Nachricht knacken. Die kann man ansonsten völlig ungesichert übertragen, die sind mathematisch unknackbar. Sogar wenn der Angreifer eine Plaintext Nachricht kennt oder sogar selber erzeugen darf, erlaubt ihm die verschlüsselte Nachricht keine Rückschlüsse auf den Inhalt folgender Nachrichten.
Es ist aber nicht 100% sicher. Die Zufallsdaten müssen absolut unabhängig sein und dürfen in keiner Abhängigkeit stehen. Sie müssten z.B. durch thermisches Rauschen.
mfg

Thomas :-)
murph
User
Beiträge: 622
Registriert: Freitag 14. April 2006, 19:23
Kontaktdaten:

Dienstag 30. Mai 2006, 15:15

ich habe mich auch einmal damit auseinandergestzt, und am besten ist dafür radioaktives material...krebs lässt grüßen
aber vllt ein lauter transistor oder so ist fälhig genug, dass das nicht nachher ermittelt werden kann...
Python 47
User
Beiträge: 574
Registriert: Samstag 17. September 2005, 21:04

Dienstag 30. Mai 2006, 22:46

Also mal ein kleines Beispiel:

Ich habe mir 1 Gb zufallsdaten genertiert. Ich verschlüssel damit jetzt sagen wir mal ein Film z.b. Ghostship. Jetzt will die NSA es wieder entschlüsseln und wir gehen mal davon aus, dass sie Genügend Geld hätten um sich genügend rechner zu kaufen. So jetzt starten sie eine Bruteforce Atacke um rauszubekommen welchen Schlüssel ich bentutzt habe. Ich habe die Zufallsdaten nochmal durch XOR laufen lassen. So jetzt bekommen die wieder die Zufallsdaten aber Sie haben keine Chance herauszubekommen was verschlüsselt wurde, weil die 1 GB daten alles sein können z.B. James Bond oder 1000 Alben Musik oder Ein Programm wie Office oder oder oder. Und eben alles mit GLEICHER Wahrscheinlichkeit.

Das kann aber nur sein, wenn die Zufallsdaten absolut unabhängig generiert wurden z.B. thermisches Rauschen
mfg

Thomas :-)
Antworten