Verschlüsselungsalgorithmen

Deine Mühen in allen Ehren was selbst zu schreiben, aber wenn dir die Daten deiner Nutzer so wichtig sind, vor allem wenn du so wenig wissen mitbringst, warum dann was selbst schreiben und nicht auf eine fertige und auditierte Lösung setzen?
Mit 2FA/MFA und Keyard wird das ganze ja noch mal umfangreicher / komplizierter.

Als Übungsprojekt kannst du dich ja trotzdem mal einarbeiten. Genug Schlagwörter und Links hast du ja jetzt bekommen.
 
D
Nilson schrieb:
Deine Mühen in allen Ehren was selbst zu schreiben, aber wenn dir die Daten deiner Nutzer so wichtig sind, vor allem wenn du so wenig wissen mitbringst, warum dann was selbst schreiben und nicht auf eine fertige und auditierte Lösung setzen?
Mit 2FA/MFA und Keyard wird das ganze ja noch mal umfangreicher / komplizierter.

Als Übungsprojekt kannst du dich ja trotzdem mal einarbeiten. Genug Schlagwörter und Links hast du ja jetzt bekommen.
DANKE, ICH MUSS IRGENDWO ANFAGEN. und ausserdem es ist ein Geschenk an die Menschen da unten
 
Mclowi243 schrieb:
die Menschen da unten
Wie bitte? Es gibt übrigens einen Haufen Software für verschlüsselte Kommunikation.

Mclowi243 schrieb:
Leute die in Afrika von Krieg geflohen sind
Wenn du denen wirklich helfen willst, dann sprich mit den einschlägigen Stellen, CCC, Amnesty International etc.etc. die wissen tausendmal besser als du von deiner Couch aus, was diese Menschen benötigen.

Mclowi243 schrieb:
ja, stimmt aber wie kann ich es hier bzw bei mir verwenden das macht mich schon seit Tage fertig
Das ist eine einzelne Zeile Code. Sowas wie:
Code:
encrypted_data = Crypto.encrypt(cleartext_data, method='AES')
Das ist jetzt natürlich erfunden, aber mehr steckt da nicht hinter.
 
  • Gefällt mir
Reaktionen: Mclowi243
Was passiert dann mit den Daten, wenn diese absolut sicher übermittelt worden sind? Kommen die dann auf Deinen Rechner? Wer kann diese Daten wie nutzen? Was passiert bei einem "Angriff von Innen" (dein Mitarbeiter will Dich ärgern und publiziert die Daten)?
 
Mit Software die Welt retten... sehr romantisch.
Deine Ambitionen sind nobel und löblich, begehst jedoch den enormen Fehler, vor lauter Altruismus und Selbstüberzeugung deinem Vorhaben einen objektiven Realitätscheck zu unterziehen.

Ich will dir eigentlich nicht den Wind aus den Segeln nehmen, aber deine Erwartungen bzgl. des Schutzes sensibler Daten von Dritten sind hochgradig unrealistisch.
Du hast scheinbar erst vor kurzem mit Softwareentwicklung begonnen und auch keinerlei tiefergehende Vorkenntnisse der Kryptologie sehr nahe stehenden Themenbereichen, wie, allgemein, Informatik und angewandte Mathematik.
Das Themengebiet "Kryptologie" ist unfassbar komplex.
In der Art, dass du davon ausgehen musst, Jahre zu brauchen, bis du damit so weit bewandert bist, Vertrauenswürdige Entscheidungen treffen und brauchbare Einschätzungen abgeben zu können.
In der Tat ist das Gebiet sogar so immens Komplex, dass selbst die größten Koryphäen (egal ob Algorithmus- und Protokoll-Design oder Algorithmus- und Protokoll-Implementierung) immer wieder mal desaströse und ungeahnte Fehler unterlaufen.
Deshalb ist es auch so wichtig, bei kryptografischen Anwendungen auf etabliertes und bewährtes zu setzen und keines Falls eigene Ideen umzusetzen.

Zu glauben, du könntest mit deinem Wissensstand mal eben schnell sichere kryptografische Protokolle umsetzen oder gar gleich eigene, sichere Protokolle neu erfinden, ist nichts anderes als gefährlich.
Nicht für dich, aber auf jeden Fall für die Personen, denen du deine Software andrehst.
Geh davon aus, dass es bei deinen ersten kryptografischen Gehversuchen besser gewesen wäre die Daten gleich gar nicht zu "verschlüsseln", weil du so viele Fehler machen wirst, dass, aus einer informierten Sicht der Dinge, offensichtlich sein wird, wie die Daten trivial in eine lesbare/verarbeitbare Form zurückzuführen sind.


Nach all dem, was ich dir eigentlich sagen will:
Schraube bitte deine Ambitionen herunter.
Deine Software wird die Welt nicht retten, auch nicht einen kleinen Teil davon.
Du darfst dein Projekt natürlich als Visitenkarte Verwendung finden lassen, aber sehe bitte davon ab, es irgendwo in einem produktiven/realen Szenario Anwendung finden zu lassen.
Sie wird nicht sicher sein!
Du wirst dir dessen nicht bewusst sein, aber du wirst deine Anwender deswegen zwangsweise in gewisser Art und Weise betrügen.

Bitte verliere dein Ziel aber auch nicht aus den Augen!
Investiere die nächsten Jahre einen angemessenen Teil deines Lebens in den Kenntnisaufbau bzgl. Softwareentwicklung und Kryptografie.
Dann kann das auch klappen.

Jetzt gerade, stellst du es dir jedoch noch deutlich zu einfach vor.
Du hast gerade eben erst den Eingang zum Kaninchenbau gefunden. Jetzt musst du dich "einfach nur noch" hineinstürzen... ;)
 
  • Gefällt mir
Reaktionen: Der Kabelbinder, Piktogramm, mental.dIseASe und eine weitere Person
blöderidiot schrieb:
Was passiert dann mit den Daten, wenn diese absolut sicher übermittelt worden sind? Kommen die dann auf Deinen Rechner? Wer kann diese Daten wie nutzen? Was passiert bei einem "Angriff von Innen" (dein Mitarbeiter will Dich ärgern und publiziert die Daten)?
blöderidiot schrieb:
Was passiert dann mit den Daten, wenn diese absolut sicher übermittelt worden sind? Kommen die dann auf Deinen Rechner? Wer kann diese Daten wie nutzen? Was passiert bei einem "Angriff von Innen" (dein Mitarbeiter will Dich ärgern und publiziert die Daten)?
Daten werden genutzt um die die Fluchtlingsströme zu überwachen im Fall des Missbrauchs werden rechtliche Schritte eingeleitet.
 
Schau dir doch mal Magic Wormhole an, dafür gibt es auch GUIs und wenn dir die Funktionen noch nicht reichen, kannst du sie ja immer noch erweitern.
 
  • Gefällt mir
Reaktionen: Mclowi243
madmax2010 schrieb:
Verschluesselungsalgorithmen selber zu implementieren erfordert erheblich mehr, als einfach nur einen ALgorithmus von wikipedia abzuschreiben.

Also hier steht, https://crypto.stackexchange.com/qu...y-simple-and-yet-secure-encryption-algorithms , der Verschlüsselungsalgorithmus Threefish, https://de.wikipedia.org/wiki/Threefish , wäre relativ einfach selber zu implementieren... (und außerdem sicher)

Man sollte auf transparente Verfahren zurückgreifen, das ist richtig, aber man kann es auch selber versuchen. Ich hab es hier mal versucht, in C++ umzusetzen:

C++:
#include <cstdint>
#include <cstring>
#include <iostream>
#include <sstream>

using namespace std;

typedef uint8_t u8;
typedef uint64_t u64;

u64 rl64(u64 x, u8 r)
{
    return (x << (r & 63)) | (x >> (64 - (r & 63)));
}

u64 rr64(u64 x, u8 r)
{
    return (x >> (r & 63)) | (x << (64 - (r & 63)));
}

void mix(u64 a, u64 b, u64 *c, u64 *d, u8 r)
{
    u64 tmp = a + b;
    *d = rl64(b, r) ^ tmp;
    *c = tmp;
}

void mixinv(u64 c, u64 d, u64 *a, u64 *b, u8 r)
{
    u64 tmp = rr64(c ^ d, r);
    *a = c - tmp;
    *b = tmp;
}

void threefish_round(unsigned nwords, u64 v[], u8 r[], u8 p[])
{
    for (unsigned w = 0; w < nwords; w += 2)
    {
        mix(v[p[w]], v[p[w + 1]], &v[p[w]], &v[p[w + 1]], r[w / 2]);
    }
}

void threefish_roundinv(unsigned nwords, u64 v[], u8 r[], u8 p[])
{
    for (unsigned w = 0; w < nwords; w += 2)
    {
        mixinv(v[p[w]], v[p[w + 1]], &v[p[w]], &v[p[w + 1]], r[w / 2]);
    }
}

void encrypt(unsigned nwords, u64 plaintext[], u64 ciphertext[])
{
    u8 key[nwords] = "haallo";

    unsigned nrounds = 72;
    u8 rot[8][2] = {
        {14, 16},
        {52, 57},
        {23, 40},
        {5, 37},
        {25, 33},
        {46, 12},
        {58, 22},
        {32, 32},
    };
    u8 perm[4][4] = {
        {0, 1, 2, 3},
        {0, 3, 2, 1},
        {0, 1, 2, 3},
        {0, 3, 2, 1},
    };
    u64 subkeys[nrounds / 4 + 1][nwords];

    u64 tweak[2] = {0};
    u64 xkey[nwords + 1];
    u64 xtweak[3] = {tweak[0], tweak[1], tweak[0] ^ tweak[1]};
    xkey[nwords] = 0xcafebabecafe;
    for (unsigned w = 0; w < nwords; w++)
    {
        xkey[w] = key[w];
        xkey[nwords] ^= key[w];
    }

    // expand the key
    for (unsigned i = 0; i < nrounds / 4 + 1; i++)
    {
        for (unsigned w = 0; w < nwords; w++)
        {
            subkeys[i][w] = xkey[(i + w) % (nwords + 1)];
        }
        subkeys[i][nwords - 3] += xtweak[i % 3];
        subkeys[i][nwords - 2] += xtweak[(i + 1) % 3];
        subkeys[i][nwords - 1] += i;
    }

    u64 v[nwords];
    for (unsigned w = 0; w < nwords; w++)
    {
        v[w] = plaintext[w];
    }
    for (unsigned n = 0; n < nrounds; n += 8)
    {
        for (unsigned w = 0; w < nwords; w++)
        {
            v[w] += subkeys[n / 4][w];
        }
        threefish_round(nwords, v, rot[(n + 0) % 8], perm[0]);
        threefish_round(nwords, v, rot[(n + 1) % 8], perm[1]);
        threefish_round(nwords, v, rot[(n + 2) % 8], perm[2]);
        threefish_round(nwords, v, rot[(n + 3) % 8], perm[3]);

        for (unsigned w = 0; w < nwords; w++)
        {
            v[w] += subkeys[n / 4 + 1][w];
        }
        threefish_round(nwords, v, rot[(n + 4) % 8], perm[0]);
        threefish_round(nwords, v, rot[(n + 5) % 8], perm[1]);
        threefish_round(nwords, v, rot[(n + 6) % 8], perm[2]);
        threefish_round(nwords, v, rot[(n + 7) % 8], perm[3]);
    }
    for (unsigned w = 0; w < nwords; w++)
    {
        ciphertext[w] = v[w] + subkeys[nrounds / 4][w];
    }
}

void decrypt(unsigned nwords, u64 plaintext[], u64 ciphertext[])
{
    u8 key[nwords] = "haallo";

    unsigned nrounds = 72;
    u8 rot[8][2] = {
        {14, 16},
        {52, 57},
        {23, 40},
        {5, 37},
        {25, 33},
        {46, 12},
        {58, 22},
        {32, 32},
    };
    u8 perm[4][4] = {
        {0, 1, 2, 3},
        {0, 3, 2, 1},
        {0, 1, 2, 3},
        {0, 3, 2, 1},
    };
    u64 subkeys[nrounds / 4 + 1][nwords];

    u64 tweak[2] = {0};
    u64 xkey[nwords + 1];
    u64 xtweak[3] = {tweak[0], tweak[1], tweak[0] ^ tweak[1]};
    xkey[nwords] = 0xcafebabecafe;
    for (unsigned w = 0; w < nwords; w++)
    {
        xkey[w] = key[w];
        xkey[nwords] ^= key[w];
    }

    // expand the key
    for (unsigned i = 0; i < nrounds / 4 + 1; i++)
    {
        for (unsigned w = 0; w < nwords; w++)
        {
            subkeys[i][w] = xkey[(i + w) % (nwords + 1)];
        }
        subkeys[i][nwords - 3] += xtweak[i % 3];
        subkeys[i][nwords - 2] += xtweak[(i + 1) % 3];
        subkeys[i][nwords - 1] += i;
    }

    u64 v[nwords];
    for (unsigned w = 0; w < nwords; w++)
    {
        v[w] = ciphertext[w] - subkeys[nrounds / 4][w];
    }
    for (unsigned n = nrounds; n > 0;)
    {
        n -= 8;

        threefish_roundinv(nwords, v, rot[(n + 7) % 8], perm[3]);
        threefish_roundinv(nwords, v, rot[(n + 6) % 8], perm[2]);
        threefish_roundinv(nwords, v, rot[(n + 5) % 8], perm[1]);
        threefish_roundinv(nwords, v, rot[(n + 4) % 8], perm[0]);
        for (unsigned w = 0; w < nwords; w++)
        {
            v[w] -= subkeys[n / 4 + 1][w];
        }

        threefish_roundinv(nwords, v, rot[(n + 3) % 8], perm[3]);
        threefish_roundinv(nwords, v, rot[(n + 2) % 8], perm[2]);
        threefish_roundinv(nwords, v, rot[(n + 1) % 8], perm[1]);
        threefish_roundinv(nwords, v, rot[(n + 0) % 8], perm[0]);
        for (unsigned w = 0; w < nwords; w++)
        {
            v[w] -= subkeys[n / 4][w];
        }
    }
    for (unsigned w = 0; w < nwords; w++)
    {
        plaintext[w] = v[w];
    }
}

void encrypt_string(string s, u64 ciphertext[])
{
    unsigned n1 = s.size();
    u64 plaintext[n1] = {0};
    for (size_t i = 0; i < n1; i++)
    {
        plaintext[i] = s[i];
    }
    encrypt(n1, plaintext, ciphertext);
}

string decrypt_string(unsigned n1, u64 ciphertext[])
{
    u64 plaintext[n1];
    decrypt(n1, plaintext, ciphertext);
    string r = "";
    for (size_t i = 0; i < n1; i++)
    {
        r += (u8)plaintext[i];
    }
    return r;
}

int main()
{
    string s1 = "Moin";
    u64 ciphertext[s1.size()] = {0};
    cout << s1 << endl;
    encrypt_string(s1, ciphertext);
    string s2 = decrypt_string(s1.size(), ciphertext);
    cout << s2 << endl;
    return 0;
}

Aufpassen: Es kann sein dass noch Fehler enthalten sind.
 
  • Gefällt mir
Reaktionen: Mclowi243
CyborgBeta schrieb:
Also [...] der Verschlüsselungsalgorithmus Threefish [...] wäre relativ einfach selber zu implementieren... (und außerdem sicher)
Ein "sicherer Algorithmus", eine tatsächlich sichere Implementierung eines Algorithmus und ein tatsächlich sicherer Einsatz eines Algorithmus sind drei verschiedene Paar Schuhe!
In allen drei Stationen kann, unabhängig von einander, gehörig was schief gehen.
Es reicht aber genau ein Schiefgang in nur einem der drei Bereiche aus, sodass damit verschlüsselte Daten nicht sicher sind!


Und du lieferst leider auch gleich die Steilvorlage dafür.
Ich will deine Umsetzung in C++ nicht bewerten und auch nicht Urteilen ob sie überhaupt richtig ist oder nicht.
(Eines kann ich mir aber nicht verkneifen... da kommt bei mir den "Monk" durch :D : Warum ist der Key in der Ver- und Entschlüsselungsroutine kein Parameter :confused_alt: )

Um meinen Punkt besser rüber zu bringen, gehen wir mal aber davon aus, dass deine Implementierung von Threefish 100% richtig und fehlerfrei ist und vernachlässigen mal, das der verwendete Schlüssel konstant ist. (Konstanten in kryptografischen Beispiel-Codes sehe ich immer als sehr gefährlich an. Unwissende tendieren dazu auch das einfach zu kopieren und bestehen zu lassen.)

Es springen einem hier gleich drei eklatante Probleme an:

1. Warum ist der Key ein String?
Ein Key, der aktiv zur Verschlüsselung von Daten genutzt wird, darf niemals ein String sein! Das liegt daran, dass die Verwendung eines Strings fast immer zur Folge hat, dass bei jedem potentiellen Byte des Schlüssels nur hauptsächlich die Werte zwischen 32 und 126 verwendet werden, statt zwischen 0 und 255. Das redurziert die Sicherheit massivst.​

2. Der zu sehende Block Cipher opperiert im ECB-Modus und ist damit per Deffinition unsicher!
ECB garantiert werder die Geheimhaltung, noch die Authentizität der verschlüsselten Daten.​
CBC mit HMAC oder SIV wären die "sicheren" Varianten der Wahl (Für Threefish! Für andere Block-Cipher gibts da besseres!), die beide Geheimhaltung und Authentizität garantieren könnten. (Natürlich vorausgesetzt: die Implementierung und Umsetzung ist fehlerfrei! Beide sind alles andere als trivial in ihrer Implementierung!)​

3. Warum ist der Key kein Derived Key?
Die Verwendung der Bits und Bytes des "Passworts" des Users direkt als Key öffnet Türen und Tore für sehr effiziente Brute-Force-Verfahren.​
Die darüber verschlüsselten Daten können in solchen Fällen nicht als sicher gelten!​
Passwörter (ganz egal in welcher kryptografischen Lebenslage!) müssen vor Verwendung immer mit einer Key-Derivation-Function abgeleitet werden. Das Ergebnis einer solchen Funktion garantiert zum einen sowohl die geforderte Länge des Schlüsselt für den Block-Cipher, als auch eine, mit unter, signifikante und nur teuer zu überwindende Hürde für Brute-Force-Verfahren.​


Problem 1. lässt sich theoretisch noch einfach selbst umsetzen.
Aber schon ab Problem 2. ist die Frage "Wäre das Einarbeiten in die Java Crypto-Bibliothek nicht besser?" mit einem sehr sehr eindeutigen "JA" zu beantworten.
Von Problem 3. brauchen wir dann gar nicht erst das Reden anfangen...

CyborgBeta schrieb:
Man sollte auf transparente Verfahren zurückgreifen, das ist richtig, aber man kann es auch selber versuchen.

Das Unterstütze ich, würde aber sogar sagen "sollte man".
Denn mit jedem Versuch kann man nur schlauer werden. (Und wenns dann nur dazu geführt hat, dass man feststellen musste, doch nicht so schlau zu sein, wie man dachte.)
Für Spielereien und Weiterbildungen ist alles erlaubt!
Sobald es aber etwas Handfestes werden soll, nutzt bitte fertig implementierte und bewährte Systeme!
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: mental.dIseASe, kuddlmuddl, Nilson und 3 andere
  • Gefällt mir
Reaktionen: Mclowi243, CyborgBeta und madmax2010
Ja, AW4 hat mit seiner Auflistung völlig recht... Ich wollte nur auf Folgendes hinaus: Es gibt Verfahren, die als sicher gelten... und man kann dann auf Bibliotheksfunktionen zurückgreifen (oder versuche, diese (am besten mit Tests dabei) selber umzusetzen).

Was man aber nicht machen sollte... sich ein eigenes, nicht transparentes Verschlüsselungsverfahren überlegen; denn dann ist es nur eine Frage der Zeit, bis das umgangen wird.

Security through obscurity ist ein Antipattern/ sollte vermieden werden.
 
  • Gefällt mir
Reaktionen: Mclowi243
Mclowi243 schrieb:
Ich bin dabei ein Software zu entwikeln um Menschen in Krisenregion in Afrika zu helfen.
Mclowi243 schrieb:
Ja, es muss End-zu-Endverschlüsselung sein. Schlüsseln werden in einer Key-card. Jeder der Zugang haben darf wird von uns eine Karte bekommen, aber ich möchte dass der Zugang mit doppelsauthentificationsverfahren sein söllte. Gegen jeder Art von Missbrauch. Weil ich Daten von Fluchling behandeln werde. Leute die in Afrika von Krieg geflohen sind
Bitte sieh von deinem Vorhaben ab! Das Einzige was sicher ist, ist dass Anfänger alle Anfangsfehler erneut begehen und so Sicherungsschicht kompromittieren. Um zu lernen ist das in Ordnung, was jedoch ABSOLUT nicht in Ordnung ist, ist es Menschen dies als sichere Kommunikation anzubieten. Vor allem, wenn diese Menschen aus Krisengebieten und mit akuter Gefährdung darauf angewiesen sind, dass ihre Kommunikation sicher ist.
Und da hier Amnesty International und der CCC (Chaos Computer Club) angesprochen wurde. Ich bin nur unbedeutend im Umfeld des CCC unterwegs, aber ich kann dir die Antwort recht sicher verraten: Lass es bitte bleiben! Du gefährdest nur sinnlos Menschenleben!

Mclowi243 schrieb:
DANKE, ICH MUSS IRGENDWO ANFAGEN.
Anfangen ist an der Stelle Code zu schreiben, diesen zu veröffentlichen und den von Nörglern um die Ohren gehauen zu bekommen, weil vom Konzept über die Dokumentation bis zur Implementierung alles übelster Müll ist[1]. Nach ein paar Jahren Erfahrung kannst du dann bei Null beginnen, das mit aller Erfahrung etwas implementieren, was das Sicherheitsaudit nach mehreren Anläufen vielleicht besteht. Vorher sollte NIEMAND deine Software einsetzen!


[1] Been there, done that
 
  • Gefällt mir
Reaktionen: mental.dIseASe, Schwachkopp und CyborgBeta
Danke an Piktogramm... Ich hab jetzt erst ganz gelesen, dass es um vom Krieg betroffene Menschen geht. Dann würde ich auch davon abraten, außer zu Übungszwecken, etwas selber zu versuchen.
 
Zurück
Oben