![]() |
AW: Krypto-Provider / Krypto-Engines - Kooperationsangebot
Bei den öffentlichen Sachen kann jeder reinsehen und Schachstellen/Backdors entdecken, welche dann auch behoben werden können.
Für "geheime" Algorithmen kann man z.B. über statistische Analysen einige Grundschlüsse ziehen und dann kann man immernoch via Reverse Engineering (des Verschlüsselungsprogramms) die Sache knacken. Siehe DEC: Der Hagen hat massig Ahnung, von der Materie, und selbst er hat da viel Zeit dran gessessen, an seinen Verbesserungen der verschiedensten Standards. Es gibt bestimmte Dinge, die man beachten sollte und selbst wenn man "denkt", man habe etwas super Sicheres erfunden, dann kann man bei der Implementierung immernoch irgendwo "Mist" bauen, womit das dann am Ende doch wieder so unsicher wie Klartext ist. Und wenn da kein Anderer da mal drübergucken kann, dann fällt das einem garnicht auf, bis es einer der "lieben" Hacker entdeckt und es bekannt macht. |
AW: Krypto-Provider / Krypto-Engines - Kooperationsangebot
Zitat:
|
AW: Krypto-Provider / Krypto-Engines - Kooperationsangebot
Zitat:
Das war ein Problem, der mangelden Kontrolle innerhalb des OpenSSl-Projektes, welcher auch in einem Closed Source Produkt auftreten kann und es bestimmt auch tut. Zitat:
@nuclearping: Steinigt den Erfinder des Messers. ;) |
AW: Krypto-Provider / Krypto-Engines - Kooperationsangebot
Zitat:
(Edit) ... Obwohl, vorm Feuer haben wir uns mit Steinmessern bekriegt. Also ja, AUF IHN! ;) |
AW: Krypto-Provider / Krypto-Engines - Kooperationsangebot
Zitat:
|
AW: Krypto-Provider / Krypto-Engines - Kooperationsangebot
Zitat:
Zitat:
Man kann auch Open-Source Software vermarkten, denke nicht, dass man damit kein Geld machen kann. Benutze lieber gut untersuchte Algorithmen, es gibt da ganz tolle Implementierungen für Delphi die sogar Crossplatform fähig sind. Schau mal hier. ![]() |
AW: Krypto-Provider / Krypto-Engines - Kooperationsangebot
Nehmen wir mal ein schönes Beispiel:
- wir erzeugen für "RndWord=Encode(RealWord)" uns ein zufälliges WordArray aus 65536(2^16) Werten im Bereich von 0..65535(0..2^16-1) per "http://www.random.org" - wir erzeugen temporär ein 2. "inverses" WordArray aus 65536(2^16) Werten im Bereich von 0..65535(0..2^16-1) um "RealWord=Decode(RndWord)" zu bekommen - das entspräche einer Keylänge von 128KByte = !1048576Bits! = !1MBit! Keylänge... - das ganze ist nur solange sicher, wie die 128KB Keytable "geheim" bleibt - wir packen die 128KB Table in den internen Flash eines MicroControlers nd schützen den auf Hardwarelevel als "ReadProtected+ExecuteOnly" - wir ergänzen noch einen Hash-Algo über den Key, sodass nur wenn der "PublicHash" stimmt die interne Logik anläuft... also der "Hashwert" identifiziert die verwendete 128KB-KeyTable - beim Sender ergäbe der "PlainText" und dann als "PublicOutput" den "PublicHash"+"CryptText"(der Hashwert vom KeyTable im Hardwareflash wird von/in der Hardware berechnet) - beim Empfänger ergäbe "PublicHash"+"CryptText" als "PublicInput" dann den wieder den "PlainText" (wenn die zum Hashwert passende KeyTable im Hardwareflash existiert) Wenn die Plaindaten stets BZIP gepackt sind, dann ist das Verfahren so sicher wie die Geheimhaltung der Hardwaremodule wo der 1MBit-Key drin ist. Das Verfahren ist "offen", nur die 1MBit KeyFiles mit z.B. von "Random.org" oder woher auch immer gefütterten Zufallssequenzen sind innerhalb der Kommunikationspartner(-gruppen) geheim. Der Anbieter/Erzeuger des Providers hat ohne passende KeyTable keinen Zugriff auf die Daten der Nutzer. Konzeptionell ähnlich mit ClientToClient Verschlüsselung arbeitet "Mega", der aktuelle FileSharer von KimSchmitz. In wie fern Anbieter von Diensten/Programmen mit "starker" ClientToClient Verschlüsselung gemäß Gesetz in der EU doch eine Hintertür für den "ManInTheMiddle" einbauen müssen, das will ich gerade gar nicht wissen. Ob ich mir das gerade ausgedacht habe, oder sowas eventuell schon existiert, das habe ich gerade vergessen. !!!Und wer erkennbar verschlüsselte Daten verschickt, erweckt nur der Spiel-/Jagdtrieb bestimmter Leute. Sowas muss dann mindestens im Alphachannel oder besser im YUV Offest eines schönen Fotos im Anhang einer netten Grußkarten-Mail "verschwinden"!!! |
AW: Krypto-Provider / Krypto-Engines - Kooperationsangebot
Zitat:
Soweit ist es noch nicht. |
AW: Krypto-Provider / Krypto-Engines - Kooperationsangebot
Die Idee finde ich richtig gut! :thumb::thumb::thumb: Natürlich müssen die Algorithmen veröffentlicht sein, ABER man kann erstens NSA & Co. mit mehreren verschiedenen Verfahren austricksen (muss ja kein Public-Key-Verfahren sein ...), weiterhin kann man verschiedene Verschlüsselungsverfahren kombinieren.
Und wenn man Hagens DEC-Varianten schon einbauen würde (ich weiß jetzt nicht, ob das Lizenzrechtlich geht und ob Hagen das möchte), hätte man schon eine ordentliche Variation an Algorithmen. Gruß Puke PS: Vielleicht könnte man ja ein Steganografie-Verfahren später noch einbauen :-D |
AW: Krypto-Provider / Krypto-Engines - Kooperationsangebot
Vielen Dank erst mal für Eure Antworten.
Ich bin immer offen für Argumente. Ich hätte auch keine Probleme damit, wenn ein Krypto-Provider eine Krypto-Engine auf der Basis von starken und "sicheren" Open Source Algorhytmen entwickelt. Man kann hier ja durchaus auch mehrgleisig fahren. Die "bessere" Variante setzt sich dann am Ende eben durch. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:20 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz