Schon ausgelaufen

Und wenn ich den Quelltext heute noch ins Netz stellen würde, hätte ich dadurch das Kerckhoff-Prinzip plötzlich verstanden?

Der 'Coder' ist nicht kryptographisch, weshalb ich dessen Quelle geheim halten muß. Andernfalls könnte ich ihn nicht mehr zur Verschlüsselung einsetzen.

Ich muß also gegen das Kerckhoff-Prinzip verstoßen, weil eine Geheimhaltung des Schlüssels allein hier nicht ausreicht. Ich habe folglich das Kerckhoff-Prinzip genauestens verstanden - bereits in den 1990ern.

Helmut Schellong, 2024-04-22 18:12:

Wenn "coder" ein Programm zu Ver- oder Entschlüsselung auf Basis kryptografischer Verfahren wäre - ja. Aber dass "coder" gar nichts mit Kryptografie zu tun hat, habe ich nicht sofort realisiert, sonst hätte ich Dir gleich gesagt, dass der ganze Hinweis von Dir darauf in diesem Kontext sinnfrei ist.

Und wieso behauptest Du dann, dass Du das Kerckhoff-Prinzip verstanden hättest, wenn Du auf ein Programm hinweist, dass nichts mit Kryptografie zu tun hat?

Wenn "coder" nichts kryptografisch ver- oder entschlüsselt, dann hat das Kerckhoff-Prinzip damit schlicht nichts zu tun.

Ich widerspreche hier. Daß das Kerckhoff-Prinzip für die Kryptographie aufgesetzt wurde, so bedeutet das überhaupt nicht, daß dieses Prinzip _nur_ für die Kryptographie nutzbar sein kann.

Die meisten Regeln/Prinzipien können oft auch in anderen Gebieten nützlich verwendet werden, als nur in demjenigen Gebiet, für das es original entwickelt wurde.

Helmut Schellong, 2024-04-22 20:01:

Nein, das Kerckhoff-Prinzip bezieht sich explizit nur auf Krypographie.

Das gilt aber nicht für das Kerckhoff-Prinzip. Hier geht es explizit um Kryptographie und die Erkenntnis, dass man den Schlüssel geheim halten muss, das die Sicherheit aber nicht dadurch gefährdet ist, dass das Verfahren zur Verschlüsselung offen zugänglich ist.

Daraus hat man später den Grundsatz entwickelt, dass Kryptografische Verfahren sogar nur dann als sicher anzusehen sind, wenn sie offengelegt und in ihrer Funktionsweise überprüfbar sind.

Was das mit deinem "Coder" zu tun haben soll, der Text in eine andere Form auf Basis von 6-Bit-Zeichen konvertiert, ohne den Inhalt zu verschlüsseln, ist für mich nicht nachvollziehbar. Ebenso wenig, wieso der Hinweis darauf von Dir als Beleg angeführt wird, dass Du das Kerckhoff-Prinzip verstanden hättest.

Du irrst Dich hier beharrlich. Der Inhalt wird _zusätzlich_ durch Schlüssel mit 64 Byte Länge verschlüsselt. Es werden mindestens 3 Runden durchlaufen, mit jeweils anderem Schlüssel.

Allerdings wird _keine_ kryptographisch erzeugte Bitfolge mit z.B. 2^68 Byte Länge erzeugt, mit deren Hilfe andere Inhalte verschlüsselt werden können. Genau deshalb kann ich die Quelle nicht offenlegen, weil man darin lesen kann, wie in einem Buch. Ich kann dem Kerckhoff-Prinzip hier also nicht folgen. Gerade weil ich dies Prinzip lange kenne, habe ich in den 1990ern überlegt, ob ich die Quelle offenlegen kann.

Dieses Prinzip kenne ich allerdings ganz unabhängig seit langer Zeit. Es ist seit langer Zeit eine Binse.

Meine Implementationen von 'Rabbit' und 'Dragon' habe ich beispielsweise veröffentlicht.

Helmut Schellong, 2024-04-23 18:06:

Das der der Beschreibung nicht zu entnehmen.

Aus

BESCHREIBUNG Das Kommando coder wandelt jeden beliebigen Dateiinhalt in einen Text um und kann solche Kodierungen wieder dekodieren. Bei der Umwandlung in eine Textform wird ein reduzierter Zeichensatz aus nur 64 verschiedenen Zeichen verwendet - anstatt 256. Daher sind solchermaßen entstandene Text-Dateien um etwa 33-35% größer als die Quelldateien. Die 64 Zeichen werden der aus 95 Zeichen bestehenden Zeichenmenge von ' ' (Space) bis '~' (Tilde) entnommen (ASCII). Voreingestellt sind zwei bestimmte Verteilungen: uuencode/uudecode (UNIX) und eMail-Standard. Bei Auswahl 'Standard' können die 64 Zeichen individuell festgelegt werden, wodurch ein brauchbarer Verschlüsselungs-Effekt entsteht!

Der Algorithmus wird 'base64' genannt. Der Zeichensatz ist : "A..Za..z0..9+/" Zeichensatz uuencode: " !.._" Das sind in beiden Fällen 64 Zeichen ('..' entspricht 'bis').

Anhang-Dateien zu eMails sind in den Mail-Ordnern in einer typischen Text-Kodierung gespeichert, wie coder sie verarbeiten kann. coder kann verwendet werden, falls ein Mail-Programm eine bestimmte Kodierung nicht beherrscht oder aus irgendwelchen Gründen nicht vornimmt. coder kann auch dabei helfen, Mail-Ordner auf ein anderes Mail-Programm zu transferieren.

(Zitat Ende)

Es ist nur angegeben, dass man statt der bei base64 üblichen 64 Zeichen auch eine eigene Liste mit 64 Zeichen angeben kann, die statt dessen benutzt wird. Von "Es werden mindestens 3 Runden durchlaufen, mit jeweils anderem Schlüssel." sehe ich da nichts. Für mich ist "coder" ein etwas erweitertes Tool für uuencode/base64.

Wenn bei es einem Verfahren nicht nur vom Schlüssel abhängt, ob man das verschlüsselte Ergebnis wieder lesbar machen kann, dann verstößt es eben gegen Kerckhoff. Da dann aber zu behaupten, man hätte Kerckhoffs Prinzip schon gekannt, als man genau dieses Verfahren entwickelt hat, ist zumindest sehr seltsam.

Ja, weil das *sind* kryptografische Verfarhen.

Arno Welzel wrote:

Du hast gekonnt alles nicht zitiert, was auf die Verschlüsselungs-Option hinweist. ================================================================================================== coder -e [-nv] [-c code64] [ quell_vname [ziel_vname]] coder -d [-sv] [-c code64] [[quell_vname] ziel_vname ] coder -e [-n] [-c code64] [ quell_datei [ziel_datei]] coder -d [-s] [-c code64] [[quell_datei] ziel_datei ] coder -A|-C[#]

coder berücksichtigt die folgenden Kommandozeilen-Optionen: ------------------------------------------------------------ [...] -c Das Argument nach dieser Option muß eine Zeichenkette aus 64 Zeichen sein. Damit wird ein selbstgewählter Zeichensatz für den Algorithmus angegeben.

-C# Es werden 16 Zeichenketten, je 64 Zeichen, ausgegeben, die zur Verwendung als 'code64' (Schlüssel) geeignet sind. Niemals wird eine Zeichenkette wiederholt. Wird eine Dezimalzahl # angegeben, gilt diese Anzahl statt 16.

coder als Verschlüsselungs-Programm: ------------------------------------ Per Option -c müssen 64 Zeichen angegeben werden. Die 64 Zeichen dürfen und sollen natürlich in völlig beliebiger Reihenfolge angegeben werden, also: Verteilung UND Vertauschung. Wichtig ist eine möglichst vielfache VERTAUSCHUNG! Jede verschiedene Angabe erzeugt eine verschiedene Kodierung. Es können mehrere Stufen hintereinandergeschaltet werden, was die Datenmenge jedesmal vergrößert. Option -A zeigt die erlaubte Zeichenmenge. Kein Zeichen darf doppelt vorkommen. Das Zeichen '=' darf nicht vorkommen.

Beispiele: Telefonnummer vierfach kodiert: 0522284540 MDUyMjI4NDU0MA== TURVeU1qSTRORFUwTUE9PQ== VFVSVmVVMXFTVFJPUkZVd1RVRTlQUT09 VkZWU1ZtVlZNWEZUVkZKUFVrWlZkMVJWUlRsUVVUMDk= Dies wurde allerdings mit -immer dem gleichen- eingebauten Zeichensatz (mit -n) gemacht! 0522284540 #b5A#}"D1b5s#w== zLz{*%@oz-*,jk4bzWcoi*== va\;vZ-(+C~;}.-^Q2^UR$y|R@~yA]U~ Q.OH8($"hMfK>(&!<M&Vp,g%p,4M#@,n62:/76OQ4p&= 815n12<4}*}4;^VPn%<o6;9(}LV.P_|L|*.\;1(AP_RX/v4a(QVn8;:.}v\= Bei vorstehender Kodierung wurden nacheinander fünf verschiedene Schlüssel von Option -C her verwendet. 11111111111111111111111 5+I}5+I}5+I}5+I}5+I}5+I}5+I}5+I= [hu0U+b-h1tCBtL`[hu0U+b-h1tCBtL`[hu0U+b-h+t= S|WC5Fb-k.CT51\(fn\5kFuTV+;vB|xuA(Ftft0t+@;EAgb~vhu.^SJ-V(t= Vorstehend ist erkennbar, daß trotz Verwendung des immer gleichen Schlüssels, die Gleichartigkeit durch die dritte Stufe beseitigt ist. a a P^== `m== ?t<TZb== bGv`q*== rsvSZV*3r\p= 6d826)+H~Lu= ntUGJv3"%5U8eEVi 9A(V4tw+aLgeW6Oy *fP+Pb}0c>SD{+kA#k+Q~\== :e@D0;E8qJuBC&q>0W~.FP== a a i~== 6A== 78I}%n== 4X|+U-== Iej%?G>}k|o= ]Wn3t+*p^@`= /2>]n3e.x_HBrj%e (P[?H_oLJ#I*o\~$ E:46xCf:7(%fx$"S!cwe7V== YW#p:~P@p~qYy~3Bp-qRb.== Vier Verschlüsselungen von 'a' mit jeweils verschiedenen Schlüsseln. Das Anhängen von '=' wird vorgenommen, damit die Länge der kodierten Daten ohne Rest durch 4 teilbar ist.

Eine Ausgabe per Option -C: w$>b!QBG"gje#16%VTRJ5-pq[K\O;r_H4o]}7@NMyl:{nfh~(/AYsvPCD,.x)m&t Z]l+B(OYzt&1s@vi*K%er4M>j.R~cV`H?uqk-g)Dd5!JU}y[T,"bQ{LW_m69aoNf 8Tn:/DC0YEA}zOFS+c.*B3_|R9Q&#XvGkI>]a(2$-yfW^pVbN\Z1U?@L6t;eq~,u D:s~gO_@R#1hiX83>\Mb64rp5$"GHQ7<fBUN2,.}|W9KxVm?E*%TSFy(&wc!n`/P AN*2{k_)6}BP/([nC:1;8m^]"V?,|U`O<Z%vjLoe4q+Fc-#a.9HQ\lX&R5@GEiIu eI0bjQ4rX,&%w^pZq)cW]+9u*D:56y@Gls[Jxv$>"_B7k?#m~Y!{;`PK1LAS}T-F L.Y}5?/Vt[EJq2#a"4UOwc\s%0v9x3pI~^PhkTeGRCAzyjBM<>@*:1HbD`d8)n!K <vIWYtxBasc*Pzuw>_-eA)o9l~4y!nFE6$(.DS\mph"{1VqLM]J2}+Zr`[GKikb; [...] Leerzeichen, = und ' werden ausgefiltert. Es wird niemals eine Zeichenkette wiederholt werden, da diese Schlüssel durch den 'Spritz'-Random-Algorithmus generiert werden.

Diese Kodierung mit dem bekannten Algorithmus base64 ist natürlich ohne Angabe von '-c schlüssel64' keine wirksame Verschlüsselung! Wenn sich in der Quelle hinten ein Zeichen ändert, ändert sich meistens auch nur ein Zeichen hinten bei der verschlüsselten Ausgabe. Aber durch Hintereinanderschaltung mit jeweils verschiedenen Schlüsseln wird es doch eine wirksame Verschlüsselung: o Außer den abgesprochenen Anwendern kennt niemand die Schlüssel. o Niemand sonst kennt die Quelle und deren Länge. o Niemand sonst kennt die Anzahl der Verschlüsselungsschritte. o Bis auf die letzte Rückwandlung ergibt sich stets unlesbarer Text. o Eine Dekodierung mit anderen als den originalen Schlüsseln in der richtigen Reihenfolge führt oft zum Abbruch des 'coder', weil oft illegale Werte außerhalb des korrekten Zeichensatzes entstehen. Der Schlüssel paßt dann nicht zum zu dekodierenden Text. Der 'coder' kann also zum Codebrechen nicht benutzt werden. o Falls ein Schlüssel gefunden wurde, der zum Text paßt, dann ist die richtige Reihenfolge der Zeichen noch gar nicht bekannt. o Falls tatsächlich ein verwendeter Schlüssel herausgefunden wird, so ist es nicht erkennbar, daß dies so ist. Mit einem Kommunikationspartner können auch verschlüsselte Schlüssel ausgetauscht werden. Nur ganz zu Anfang muß eine sichere Übergabe stattfinden.

WARNUNGEN Bei Angabe von Code-Zeichen per Option -c sollte kein Zeichen (später intern) doppelt vorhanden sein, es kann sonst nicht eindeutig zurück-dekodiert werden! In einem solchen Fall erfolgt ein Warnhinweis.

Bei Kodierung/Dekodierung muß natürlich der gleiche Schlüssel verwendet werden.

HINWEISE coder als Verschlüsselungs-Programm: Der coder sollte keinesfalls als einzige Stufe verschlüsseln! Mindestens eine starke Verschlüsselung oder zwei coder-Stufen sollten unter einer abschließenden coder-Stufe liegen. Der stärkste Verschlüsselungseffekt entsteht grundsätzlich durch die Hintereinanderschaltung von unterschiedlichen Algorithmen. Das bildet eine Barriere und vernebelt BruteForce-Versuche.

Der offizielle Zeichensatz für 'base64' ist: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ Index 0 bis 63. Da lag es nahe, eigene als Kodierungs-Schlüssel zu verwenden: w='D;](IF@gx0B^5[iQf\h+bvS1k:AEdV{UJW.paLrnTN$-lu6s~}H/tC|q,y4)j`2M' conv -S w; echo "$w" #sortieren $()+,-./012456:;@ABCDEFHIJLMNQSTUVW[\]^`abdfghijklnpqrstuvxy{|}~ Durch hintereinander geschaltete solche Verschlüsselungen entsteht eine sichere, praktisch nicht brechbare Verschlüsselung. [...] ==================================================================================================

Vorstehend wird mehrfach der Satz 'coder als Verschlüsselungs-Programm:' verwendet. Von Dir komplett ignoriert.

Wenn die Verschlüsselungsoptionen nicht benutzt werden, verwendet coder interne festgelegte Schlüssel, die offengelegt sind. Andernfalls werden andere, wählbare Schlüssel verwendet. Folglich ist die Dekodierung/Entschlüsselung allein vom Schlüssel abhängig.

Deine Argumentation ist abwegig. Beispielsweise auch 'Rabbit' verwendet einen Algorithmus, in den der Schlüssel injiziert und eingearbeitet wird. Im 'coder' ist dieser Algorithmus der base64-Algorithmus, in den der Schlüssel eingeflochten wird. In jedem Fall ist der Schlüssel das unbekannt verwürfelnde Element.

| for (i=0; i<8; ++i) { | if (i&1) X[i]= K[(i+5)%8]<<16 | K[(i+4)%8], C[i]= K[i]<<16 | K[(i+1)%8]; | else X[i]= K[(i+1)%8]<<16 | K[i], C[i]= K[(i+4)%8]<<16 | K[(i+5)%8]; | }

Der Schlüssel K wird in X und C bereits schwach verwürfelt eingeflochten. Damit werden 4 Leerrunden des gesamten Algorithmus durchgeführt - vor einer ersten Ausgabe.

Deshalb können diese offengelegt werden, coder jedoch nicht.

So brauchbar, wie eine

Für mich auch. Du solltest Dir spätestens ab diesem Zeitpunkt die Mühe sparen. Sie ist vergebens.

Das war zu vermuten.

Und weil diese Deine Implementierungen wegen "Never roll your own crypto" vollkommen bedeutungslos sind, mit an Sicherheit grenzender Wahrscheinlichkeit keinem ernstzunehmendem Review unterzogen wurden, wird sie auch niemand einsetzen, der noch alle Tassen im Schrank hat. Es ist natürlich vollkommen sinnlos, Chuck Schellong auf

Das bedeutet rein gar nichts. Dual_EC_DRBG ist auch ein kryptografisches Verfahren und dennoch...

Du redest hier kompletten Bullshit, und zeigst eindrucksvoll, daß Du absolut keinen Schimmer vom Thema hast.

Alle meine Implementationen von kryptographischen Algorithmen erzeugen eine Ausgabe, die jeweils identisch mit der Referenz-Ausgabe ist. Folglich habe ich alle diese Implementationen 100% korrekt implementiert.

Es ist einfach bedeutungslos (im Kontext), was Du hier schreibst. Ich sehe eine Ähnlichkeit mit den Ausgabeformulierungen von ChatGPT.

Und ich habe übrigens keinen kryptographischen Algorithmus entwickelt, sondern einen nicht-kryptographischen Algorithmus um eine Eingabemöglichkeit eines Schlüssels erweitert. Das habe ich bereits mehrfach hier erläutert.

Was wird denn mit dem Schlüssel gemacht?

Versuchst Du uns hier gerade zu erzählen, dass es nicht-kryptographische Verschlüsselungsalgorithmen gäbe und erwartest dass wir nicht vor Lachen am Boden liegen?

Solange jemand die Dokumentation zum Algorithmus nicht gelesen hat, halte ich mich sehr zurück, eine Diskussion zu eröffnen, weil dabei zu viel geistiger Dünnschiß resultierte.

Das ist zweifellos zutreffend! Ein bisher leider allzu seltener Fall von Selbsterkenntnis! Aber Respekt, du scheinst es doch noch zu lernen

MfG Rupert

Volker Bartheld, 2024-04-25 08:52:

Zumindest hat Schellong Rabbit und Dragon nicht selber erfunden:

Ich habe den Link bereits [15.04.2024, 20:06] vor Wochen selbst gepostet. Ich habe nie behauptet, irgendeinen kryptographischen Algorithmus erfunden zu haben. Jedoch habe ich eine Reihe von solchen Algorithmen implementiert: Spritz, Rabbit, Dragon, sha2_256, sha2_512, sha3_256, sha3_512 (Keccak), ...

Wie oft muß ich wiederholen, daß 'coder' ein base64-Umsetzer ist, dem ich lediglich eine Schlüssel-Eingabe-Option hinzufügte.

Ich bin im Verteiler einer Krypto-Gruppe von internationalen Hochschulen. Von daher habe ich: \u\helmut\educ\crypto\dieharder \u\helmut\educ\crypto\handbuch \u\helmut\educ\crypto\test \u\helmut\educ\crypto\About_the_Professionalization_of_the_In.pdf \u\helmut\educ\crypto\Analysis_and_Design_of_Symmetric_Cryptog.pdf \u\helmut\educ\crypto\Analysis_and_Design_Security_Primitives.pdf \u\helmut\educ\crypto\BSI-TR-02102.pdf \u\helmut\educ\crypto\Chapter_from_the_Handbook_of_A.pdf \u\helmut\educ\crypto\Crptography_schneier.pdf \u\helmut\educ\crypto\Cryptography_A_Textbook_fo.pdf \u\helmut\educ\crypto\Cryptography_An_Introduction_3rd_Edition.pdf \u\helmut\educ\crypto\Cryptography_and_NetworkSecurity.pdf \u\helmut\educ\crypto\Cryptography_Book.pdf \u\helmut\educ\crypto\Cryptography_handbook.pdf \u\helmut\educ\crypto\Cryptography_Intro.pdf \u\helmut\educ\crypto\Cryptography_Introduction.pdf \u\helmut\educ\crypto\Cryptography_Quanten.pdf \u\helmut\educ\crypto\Cryptography_Randomness.pdf \u\helmut\educ\crypto\Cryptography_SE_05.pdf \u\helmut\educ\crypto\Cryptography_Theory_and_Practice.pdf \u\helmut\educ\crypto\Cryptography_tutorial.pdf \u\helmut\educ\crypto\Cryptography_ZHQM_ZMGM_Z.pdf \u\helmut\educ\crypto\Cryptologyy_Trends.pdf \u\helmut\educ\crypto\enisa_Crypto_October_2013.pdf etc.

Ich könnte ein Seminar abhalten, das die Fähigkeit vermittelt, wie kryptographische Algorithmen kreiert und implementiert werden können.

Der base64-Coder im Verschlüsselungs-Modus mit 3 Runden entspricht ungefähr der Wirkung des Rabbit-Algorithmus.

Diejenigen Fachleute, die solche Aufgaben konkret bis zum Schluß bewältigen können, einschließlich Implementierung, in Betrieb nehmen, Testen, sind rar gesät.

Deshalb ist es auch fragwürdig, von Quellen-Offenlegung zu reden, weil die Auswertung der Quelle nur von meisterhaften Programmierern sinnvoll vorgenommen werden kann. Die meisten werden zunächst am Code-Stil des Anderen herummäkeln - und hätten sich dadurch bereits völlig disqualifiziert.

Man kann den Schlüssel eingeben und danach wird er ignoriert?

gelesen und verstanden? Wohl kaum.

Deine Studenten lägen vor Lachen auf dem Boden.

Selbst der Rabbit-Algorithmus ist ein Exot, der obendrein auch noch ineffizienter ist als AES (cpb etwa doppelt so hoch). Klar denkende Menschen benutzen eine optimierte Bibliothek, die vielleicht auf geeigenter Hardware auch noch die vorhandenen Hardwarefunktionen benutzt.

Und was ist der Sinn darin?

Und wenn?

Hi Marc et al

warum füttert Ihr den Zweig eigentlich noch?

Marte

Security by Obscurity. Die zweite goldene Regel der Kryptografie. Die erste ("Never roll your own crypto!") hatten wir ja schon abgehakt.

Volker

Ich trainiere dzt. ein LLM und brauche noch Input um SchellongGPT zu erschaffen. Das lasse ich dann auf dse los und wir haben Ruhe.

Volker

Ich sagte doch bereits, daß eine Diskussion mit jemandem, der nicht die Dokumentation gelesen hat, geistigen Dünnschiß ergibt. Hier haben wir einen solchen Fall!

Die Dokumentation zeigt vielfach die Wirkung von Schlüsseln.

Auf 'Spritz' wird dort nicht eingegangen. Willst Du diesen Algorithmus irgendwie lächerlich machen?

Größtenteils sind das _keine_ Standardwerke.

Ich habe alle mehr oder weniger vollständig/intensiv gelesen und verstanden.

Diejenigen, die nicht lachen, hätten dann anschließend zu großen Teilen diese Fähigkeit.

Es ist mir bekannt, daß neuere intel-Prozessoren AES mittels Instruktion unterstützen. Die Instruktion RANDOM gibt es dort ebenfalls. Die müßten allerdings in Assembler angegeben werden.

Ich will AES als eine Block-Chiffre nicht verwenden.

Die Semantik dieses Wortes: eigenwillig · unangepasst · unbequem · ungewohnt · ungewöhnlich · unkonventionell unvertraut · unüblich · wie man ihn nicht alle Tage trifft · mit Ecken und Kanten fig. · sperrig fig.

Bekannte Ansätze zum Angriff sind nicht verwendbar.

Meisterhafte Programmierer erkennen mit hoher Wahrscheinlichkeit den programmierten Ablauf auch im Detail korrekt und können ihn oft bewerten.