AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Brauche Hilfe mit der DEC_5_1c

Ein Thema von Wishmaster · begonnen am 14. Sep 2006 · letzter Beitrag vom 15. Sep 2006
Antwort Antwort
Wishmaster

Registriert seit: 14. Sep 2002
Ort: Steinbach, MB, Canada
301 Beiträge
 
Delphi XE2 Architect
 
#1

Brauche Hilfe mit der DEC_5_1c

  Alt 14. Sep 2006, 05:15
Hi

Hier ist etwas wo ich absolut keinen plan von habe!

Was ist die sicherste Bzw. beste Methode um Passwörter (Text) zu Verschlüsseln und zu Speichern.

Wie kann ich überprüfen ob das Passwort Bzw. Text Korrekt decodiert wurde?

Ich dachte daran vor und am ende eines Passwortes einen eindeutigen text (Zeichen) einzufügen dann das das ganze inc. Passwort zu Verschlüsseln

Das ganze soll mit der DEC_5_1c realisiert werden.


Hat jemand von euch schon mal daran gedacht ne Komponente zu schreibe, ich meine so wie dcpcrypt2 oder LockBox um die Handhabung der DEC_5_1c zu erleichtern.


BDS2006
  Mit Zitat antworten Zitat
Der_Unwissende

Registriert seit: 13. Dez 2003
Ort: Berlin
1.756 Beiträge
 
#2

Re: Brauche Hilfe mit der DEC_5_1c

  Alt 14. Sep 2006, 10:14
Zitat von Wishmaster:
Was ist die sicherste Bzw. beste Methode um Passwörter (Text) zu Verschlüsseln und zu Speichern.
Hast du eigentlich schon mal die Suche bemüht? Ich glaube diese und/oder sehr ähnliche Fragen wurden schon öfters gestellt und sicherlich auch schon beantwortet. Mit Sicherheit kann man sagen, dass kein Verfahren sicher ist. Es gibt halt nur einen Punkt, der im Moment als ausreichend sicher durchgeht. Die Frage ist also, was benötigst du im Moment für eine Sicherheit? Es dürfte keine pauschale Antwort wie Verfahren XYZ ist super für jede Verschlüsselung geeignet geben. Es kann auch mehr als ein Verfahren in Frage kommen. Ansonsten schränkst du dich doch auf die DEC_5_1c ein, da gibt es doch nur endlich viele Verfahren. Da kannst du dann leicht mal selber schauen, wo deren Vor- und Nachteile liegen und als wie sicher die gelten (google und die DP helfen). Wenn du dann zu einem der Verfahren eine Frage hast, die beantwortet man dir bestimmt gerne (wahrscheinlich tut das aber die Forensuche schon).

Zitat von Wishmaster:
Wie kann ich überprüfen ob das Passwort Bzw. Text Korrekt decodiert wurde?
Auch da dürfte es einige Möglichkeiten geben. Ganz im Sinne der DEC könntest du ja einfach einen Hash über dein Passwort berechnen. Stimmt der mit dem entschlüsselten Text überein stehen die Chancen recht gut, dass du richtig entschlüsselt hast.

Zitat von Wishmaster:
Hat jemand von euch schon mal daran gedacht ne Komponente zu schreibe, ich meine so wie dcpcrypt2 oder LockBox um die Handhabung der DEC_5_1c zu erleichtern.
Wie sieht es denn da bei dir aus? Hast du schonmal drüber nachgedacht?
Ich meine einerseits gibt es jmd., der sich überhaupt mal die Mühe gemacht hat diese Units zu erstellen (und da steckt sicher einiges an know-how und Arbeit drin). Da würde ich dann erstmal schauen, ob der sich nicht auch bei der jetzigen Benutzung seine Gedanken gemacht hat! Und ob es dann Lizenzrechtlich ok ist, daran was zu ändern sollte man auch schauen (kenn die Lizenz nicht).
Zudem wäre es hier doch ganz nett, wenn du auch sagen könntest, was genau an der Benutzung dich störrt. Das ganze noch als eigener Thread und die Leute könnten ja mal schauen...

Gruß Der Unwissende
  Mit Zitat antworten Zitat
Wishmaster

Registriert seit: 14. Sep 2002
Ort: Steinbach, MB, Canada
301 Beiträge
 
Delphi XE2 Architect
 
#3

Re: Brauche Hilfe mit der DEC_5_1c

  Alt 15. Sep 2006, 01:03
Hi

Ja! Ich habe die suche bemüht. Leider nichts Passendes gefunden.
Und wie ich schon oben erwähnt hatte, habe ich von diesem Thema keine Ahnung.

Zbw. Ich wusste nicht was der unterschied zwischen ECB, CBC, CFB, … ist. Mittlerweile habe ich mich schlau gemacht.

Und Ja! Ich habe schon daran gedacht ne Komponente zu schreibe. das ich auch ein Grund warum ich diese fragen stelle.

Ich bestreite auch nicht das da fiel arbeit dahinter steckt, und ich will auch nicht undankbar erscheinen!!!

Ich denke Lizenzrechtlich dürfte es da keine Problehme geben weil ich DEC_5_1c nicht verändern will.

Mir ginge es darum Installierbare Komponenten zu schreiben. Ne extra Komponente für TBlowfish, TTwofish, TRijndael und so weiter, abgeleitet von DEC_5_1c. damit man nicht für jedes Programm das eventuell 2, 3 tausend Zeilen gros ist. Noch ne menge code einfügen muss nur um ne Passwort abfrage einzubauen.

Das ganze sollte ungefähr so aussehen.
Delphi-Quellcode:

unit Dec_Rijndael

interface

uses
  ....?


type
TRijndael = class(TComponent)
private


public
  Property Mode ECB, CBC, CFB, was auch immer
  Property KeySize 128, 256
  Property Hash mode ?????

// Eventuell noch par Events
  OnProgress
  OnError

 function EncodeString(Source: Binary) : Binary;
 function DecodeString(Source: Binary) : Binary;
Das soll nur als Beispiel diene damit versteht was ich meine.


http://www.kuno-kohn.de/crypto/
  Mit Zitat antworten Zitat
Benutzerbild von Luckie
Luckie

Registriert seit: 29. Mai 2002
37.621 Beiträge
 
Delphi 2006 Professional
 
#4

Re: Brauche Hilfe mit der DEC_5_1c

  Alt 15. Sep 2006, 01:06
Der Autor, Hagen, hatte seine guten Gründe keine Komponenten zur Verfügung zu stellen. Und in einem seiner vielen Beiträge zu dem Thema hat er bestimmt auch schon die Unterschiede zwischen ECB, CBC, CFB erklärt. Seine Beiträge sind leider etwas verstreut in der Delphipraxis, wenn du aber mal nach verschlüssel und explizit negah suchst wirst du viele interessante Beiträge von ihm finden, die mit Sicherheit einiges klären werden.

Matze oder so hatte mal ein PDF mit seinen Beiträgen zusammengestellt, leider weiß ich nicht, was daraus geworden ist. Ich muss ihn deshalb sowieso mal ansprechen.
Michael
Ein Teil meines Codes würde euch verunsichern.
  Mit Zitat antworten Zitat
Benutzerbild von negaH
negaH

Registriert seit: 25. Jun 2003
Ort: Thüringen
2.950 Beiträge
 
#5

Re: Brauche Hilfe mit der DEC_5_1c

  Alt 15. Sep 2006, 01:58
Zu den TComponent Varianten der Cipher:

Davon halte ich überhaupt nichts. Frage dich wann eine solche Komponente erzeugt wird und wie lange sie lebendig ist. Nun frage dich wie lang die Zeitspanne ist in der man sicherheits relevante Aufgaben erledigen muß.

Und nun, nachdem du festgestellt hast das eine Komponnete quasi die ganze Zeit aktiv ist und die Sicherheitsaufgabe im Program aber nur wenige Millisekunden zu dauern hat, fragst du dich warum es sicherer sein muß die Zeitspanne in der man Kryptographie im Program benutzt so kurz wie nur möglich zu halten.

Es ist ein kryptographsiches Sicherheitsrisiko ein Passwort und den initialiserten Cipher als Komponnete die ganze Zeit in der ein TForm offen ist, im Speicher zu halten. Damit bietest du Trojanern nur unnötige Angriffsziele und auch den notwenigen Zeitraum dafür.

Zudem macht eine Komponente dann ganzen Kram nur noch unübersichtlicher. Im Normalfalle möchtest du zb. eine Datei verschlüsseln.

Also wählst du
1.) den Cipher deines Vertrauens
2.) den Cipher Modus deines Vertrauens
3.) den Hash deines Vertrauens

aus und baust dir zwei simple Funktionen:

procedure EncodeFile();
procedure DecodeFile();

und allozierst innerhalb dieser Funktionen deinen Cipher deines Vertrauens, wandelt das Password mit einem Zufallssalt und einem Hash deines Vertrauens, zb. mit THash_SHA1.KDFx(), in einen sicheren Sessionkey um, initialisierst damit den Cipher nachdem du diesen mit dem Cipohermodus deines Vertrauens initialisert hast und verschlüsselst/entschlüsselt die angegebene Datei. Fertig. Zwei simple Funktionen, 1 Cipher, 1 Hash und mit minimalstem Aufwand steht das System.

Das nun in DEC so viele verscheidene Algorithmen drinnen sind hat nur einen Grund

Sicherheit

genauergesagt Verfahrenssicherheit. Das beduetet das du ohne großem Aufwand in Zukunft wenn der Cipher deines Vertrauens eben nicht mehr vertrauenswürdig ist, auswechseln kannst.

Es besteht überhauptnicht die Notwendigkeit in einer Software hunderte verschiedener Verschlüsslungen dem Benutzer anzubieten. Nein, ich sehe das eher als eine Unfähigkeit des Entwicklers sich nicht entscheiden zu können und deshalb alles was möglich ist anbietet. Das ist unseriös.

Denoch: schaue mal ob du die alte Version 3 oder früher bekommst. Darin sind die Komponenten TCipherManager und THashManager integriert (als DEMO wohlgemerkt)
Denn anstatt nun 100 Komponneten zu erzeuge, jeweils zb. TCipher_Rijmdael_Component und TCipher_Blowfish_Component und TCipher_IDEA_Componet reicht eine EINZIGSTE TCipher_Componnet vollkommen aus in der man den zu benutzenden Algo. auswählt.

Ehrlich gesagt hasse ich das. Man kann aus allem eine Komponnete machen, sogar aus ShellExecute(ProgrammName) aber ich bezweifle ob so ein Übereifer eine wirklich nützliche Sache darstellt.

So, das soll jetzt keine Ablehnung meinerseits darstellen, ich helfe jedem gerne. Ich möchte dir aber aufzeigen warum ich eben meine Bibliothek so gecodet habe und nicht anders. Und ehrlich gesagt bin ich auch ein bißchen stolz darauf das DEC so viele gute Kritiken im WEB bekommen hat. Das liegt eben auch daran das sich das DEC auf das eigentliche Ziel konzentriert: eine kompakte auf das Notwendigste und denoch in Zukunft flexible Bibliothek zu sein. Um das zu ereichen muß man sich auf die minimalste Schnittstelle einigen die die geringsten Abhängigkeiten in ZUkunft zu erwarten hat. TComponnet ist keine solche Schnittstelle. Wenn die VCL irgendwan ausgestorben ist so wird man DEC immer noch in irgendeinem FreePascal zum laufen bekommen, eben weil es sich auf das Wesentlichste beschränkt.

Nun Komponenten sind sehr einfach zu benutzen, das ist unbestritten und gerade das macht mir Sorgen. Denn DEC ist keine readymade Software sondern eine Bibliothek. Der Benutzer vom DEC muß sich also immer intensiv mit Kryptographie beschäftigen damit er DEC auch sicher benutzen kann. Eine TComponent würde auch von den sogennaten "Drag&Design" Programmieren benutzt werden ohne das sie überhaupt wissen was sie da tuen. Das ist ein Sicherheitsrisiko und ich möchte nicht mit meinem Namen in der Copyright Box einer solchen Anwendung drinnenstehen.

Im alten DEC hatte ich wie gesagt zwei Komponneten drinnen. Diese waren eigentlich nur als Demo für spezielle Funktionen im DEC angedacht und brachten mir in den folgenden 2 Jahren nur Ärger ein. Ständige EMails von Supportanfragen in denen ich darauf verweisen musste das es eine schlechte Idee ist diese Komponenten zu benutzen.

Da alle TCipher von einer Basisklasse abgeleitet wurden und demzufolge in ihrem Interface fast 100%'tig zueinander identisch sind wäre es Dummheit nun all diese Klassen in jeweils eigene Komponneten zu verfrachten. Diese Zeit hätte ich nicht und im Grunde versuche ich eine Arbeit nur einmal und nicht 100'mal zu machen. Ergo: wenn eine Komponente dann kapsel darin die Auswahl der TCipher Klasse pere Namen oder Dropdown Liste quasi als Property dieser Komponente. So brauchst du ur 1 Komponente erstellen die mit allen TCipher Klassen arbeiten kann. Das macht zb. für eine

TPasswordProtectionComponnet oder TFileEncrytionComponnet oder TStreamEncryptionComponnet durchaus Sinn. Bei diesen Komponneten bestimmt deren Aufgabe ihr Design und meine TCipher Klassen sind nur auswählbare Eigenschaften dieser Komponenten. Das heist auch das erst zum wirklich wichtigen Zeotpunkt und auch nur für die Dauer dieser wichtigen Operation ein TCipher erzegt wird und gleich wieder zerstört wird durch diese Komponenten. Und ich würde mch sogar freuen, da ich nun bei der nächsten Frage wie man sehr einfach mit DEC ein Passwort schützen kann auf deine TPasswordProtectionComponet verweisen kann

Gruß Hagen
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 03:47 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz