Entwickler-Ecke

Algorithmen, Optimierung und Assembler - Verschlüsselungseffektivität überprüfen


nullplan001 - Fr 07.04.06 17:53
Titel: Verschlüsselungseffektivität überprüfen
Hi all,
ich bin dabei, ein Mailprogramm zu schreiben. Dazu muss man auch die Passwörter abspeichern (momentan bin ich noch bei Single Tasking, was bedeutet, dass ich momentan nur einen POP3- oder SMTP-Server bedienen kann.) Ich will mir jetzt nicht nachsagen lassen, ich schreibe die Passwörter einfach so in die Registry, also habe ich da ein Verfahren entwickelt. Wie kann ich die Effektivität meines Algorithmus überprüfen. Ich will ja nicht, das mein Programm kaum auf dem Markt ist, und schon ist die Verschlüsselung geknackt. Ich möchte vor allen Dingen auch die Resistenz gegen aktive Angriffe testen, also wo jemand haufenweise Passwörter verschlüsseln lässt und guckt, was damit passiert. Den Algorithmus zur Verschlüsselung werde ich verständlicherweise nicht posten.
Tschö,
nullplan


AXMD - Fr 07.04.06 19:04
Titel: Re: Verschlüsselungseffektivität überprüfen
user profile iconnullplan001 hat folgendes geschrieben:
Den Algorithmus zur Verschlüsselung werde ich verständlicherweise nicht posten.


Damit ist dein Verfahren schonmal nicht vertrauenswürdig. Suche bei Google KERKHOFF'SCHES PRINZIP
Abgesehen davon gehört das Topic dann auch nicht in die Algorithmensparte - wenn der Algorithmus nicht bekannt ist.

AXMD


zemy - Fr 07.04.06 19:59

Regel 1 bei Kryptographie von Laien:

solls sicher werden, nehm was bekanntes!


Such dir was hübsches aus (Wiki hilft da weiter) und nehm den, der dir am sympatischsten (soll heißen für deinen Fall am zweckmäßigsten) ist. Falls du das machen solltest, kannst du deine Prozedur dann mal online stellen? Würde mich spaßeshalber interessieren ;)

MfG


delfiphan - Fr 07.04.06 20:31

Naja, die Protokolle sind ja sowieso Cleartext. Weswegen sich die Mühe machen das ganze auf dem Computer zu verschlüsseln?

Jedenfalls wenn du's verschlüsselst musst du den Schlüssel nicht im Programm speichern, das wäre Unsinn. Du müsstest die Passworter mit einem anderen, benutzerdefinierten Schlüssel verschlüsseln. Sonst kann man einfach dein Programm dekompilieren und voila.


nullplan001 - Fr 07.04.06 20:34

Hmpf... das hatte ich nicht beachtet. (Das mit der kerckhoffschen Regel) Also mein Algorithmus basiert auf Stringverschlüsselung über xor. Allerdings mit einem zufallsgenerierten Schlüssel. Wenn ich den Wert dann in die Registry schreibe, sieht das so aus: Es ist ein Hex-Wert (REG_BINARY). Als erstes steht dort die Länge des eigentlichen Wertes, und dann kommt der chiffrierte String. Und dann darf ich nach Kerkhoffschem Prinzip nicht weierreden. Die schlauen wissen jetzt, was dann kommt. Das Auslesen des Schlüssels, unter dem mein Programm registriert ist, zeigt folgendes:

Quelltext
1:
2:
password REG_BINARY 87,54,AF,21,89,55,31,80,4A,F5,C8,54,23,88,25,1A,CD
key REG_BINARY 08,2B,50,7E,EB,2F,06,1A,43,45,25,12,87,5F,6A,7B,2D

Und dieses Wertepaar maskiert das Wort "nullplan". Tja,wie auch immer das funktioniert. Auf Anfrage stelle ich gern weitere Wertepaare zur Verfügung.
Tschö,
nullplan
P.S.: Na gut, ihr habt gewonnen. Nachfolgend meine Unit:

Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
{Wie aus der Randspalte ersichtlich ist, handelt es sich um Quelltext für FreePascal.}
{Smartlinking bedeutet nur, dass nicht jede Funktion in Programme gelinkt wird, die diese Unit einbinden.}
{Nur die benötigten. Mode ist ein notwendiger Syntax-Switch. Beide können ausgehebelt werden.}
{$SMARTLINK ON}
unit wscrypt;
{$MODE OBJFPC}
interface
  type Twscrypt = class
    procedure encrypt (clear:shortstring; var cipher:shortstring; var len:longword);
    procedure decrypt (cipher:shortstring; len : longword; var clear:shortstring);
  end;

implementation
  procedure Twscrypt.encrypt(clear: shortstring; var cipher:shortstring; var len:longword);
  var
    key : shortstring;
    i : longword;

begin
  randomize;
  for i := 1 to length(clear) do key[i] := chr(random(254) + 1);
  for i := 1 to length(clear) do cipher[i] := clear[i] xor key[i];
  len := length(cipher);
  cipher := cipher + key;
end;

procedure Twscrypt.decrypt(cipher : shortstring; len: longword; var clear:shortstring);
var
  key : shortstring;
  i : longword;

begin
  key := copy (cipher, len+1, length(cipher) - len);
  delete (cipher, len+1, length(cipher) - len);
  for i := 1 to length(cipher) do clear[i] := cipher[i] xor key[i];
end;
end.

Das ist nur die reine Codierung. Von Reinschreiben in die Registry steht da noch gar nichts.
Anm.: Shortstrings sind in Delphi normale Strings (in FreePascal meckert er dann rum wegen Typkonversion und so). Viel Spaß mit der Unit.
Achso, und die Protokolle sind eben nicht alle Plain Text. Z.B. ESMTP läuft mit Base64. und wenn ich dazu noch TLS oder SSL nutze, gibt es rein gar nichts lesbares mehr.
P.P.S.: Na gut, nachdem der Trick jetzt raus ist (wer es nicht geschnallt hat: Password ist zufällig erzeugt, Key ist das verschlüsselte Passwort, mit dem ersten Byte als Originallänge), werde ich mich wohl auf ein anderes Verfahren stützen. Ich frage mich, wie man asymetrisch verschlüsselt. Ich meine, eine Tür mit einem Schlüssel zuzuschließen und sie nur mit einem anderen wieder aufzubekommen, ist nicht natürlich, oder?


zemy - Sa 08.04.06 11:45

Deine Prozedur hat wirklich ein geringes Sicherheitspotential. (Sorry) Ein einfaches XOR hält zwar erstmal ein ScriptKiddie davon ab, die Registry auszulesen. Wenn man sich aber länger damit beschäftigt (z.B. das Bitmuster anschaut), fällt es schnell auf....

Zu den asymetrischen Verschlüsselungen: Mit der Tür ist das natürlich schlecht erklärbar. Aber mit nem Briefkasten klappt das schon eher. Alle, die wissen wie man an den Einwurfschlitz kommt, können Briefe einwerfen. Aber nur der, der den Schlüssel hat, kann die Briefe auch entnehmen... Ist aber vieleicht nicht das optimale für dein Programm (asymetrische Schlüssel sind aufwendig und ver- und entschlüssler sind die selben Personen)

Für dich ist wohl eher was symetrisches geeignet. Die Frage ist blos, wie hebt man da den Key auf?

MfG


DaRkFiRe - Sa 08.04.06 13:37

Verschlüsselungsverfahren unbekannt / nicht veröffentlicht??? Weniger Angriffsmöglichkeiten - Kerkhoff'sches Prinzip schön und gut...


Ach ja - desweiteren: bei XOR Verschlüsselung kann man den CBC Mode benutzen, zusammen mit einem Blockbasierten Wert einer Tabelle, der zusätzlich das Bitmuster verschleiert.


MrSaint - Sa 08.04.06 13:50

Also wenn es nur um die "verschlüsselung" von Passwörtern geht, verschlüsselt man die normaler weise gar nicht! Man erzeugt von dem Passwort einen Hash (MD5, SHA1 oder ähnliches) und speichert den. Wenn dann ein Benutzer ein Passwort eingibt überprüft man den Hash von diesem mit dem in der Registry gespeicherten. So ein Hashing hat eben den Vorteil, dass man aus dem Hash die eigentlichen Daten nicht zurückrechnen kann.


MrSaint


AXMD - Sa 08.04.06 13:55

user profile iconMrSaint hat folgendes geschrieben:
Also wenn es nur um die "verschlüsselung" von Passwörtern geht, verschlüsselt man die normaler weise gar nicht! Man erzeugt von dem Passwort einen Hash (MD5, SHA1 oder ähnliches) und speichert den. Wenn dann ein Benutzer ein Passwort eingibt überprüft man den Hash von diesem mit dem in der Registry gespeicherten. So ein Hashing hat eben den Vorteil, dass man aus dem Hash die eigentlichen Daten nicht zurückrechnen kann.


Eben deshalb sind Hashes hier unbrauchbar ;). Das Passwort muss ja wieder an den Mailserver übetragen werden - und da hilft der Hash wenig ;)

AXMD


MrSaint - Sa 08.04.06 14:00

user profile iconAXMD hat folgendes geschrieben:
Eben deshalb sind Hashes hier unbrauchbar ;). Das Passwort muss ja wieder an den Mailserver übetragen werden - und da hilft der Hash wenig ;)



Hmm... man sollte nicht zwischen dem Lesen eines Threads und dem Beantworten was anderes machen :lol: ich war beim Beantworten der Meinung, dass es um ein Passwort geht, welches das ganze Programm sperrt *tststs*


:D


MrSaint


DaRkFiRe - Sa 08.04.06 14:21

Aus Hashes kann man das eigentliche Passwort nicht zurückrechnen?

Hashes komprimieren nicht, es gehen Informationen verloren - demnach erzeugen mehrere Strings einen gleichen Hash - man spricht von Kollision.

MD5: 128bit
SHA1: 160bit

Man hat das Passwort: P
Ein anderer (gut gewählter String): A
MD5-Hash von P: M(P)
SHA1-Hash von P: S(P)

MD5-Hash von A: M(A)
SHA1-Hash von A: S(A)


Also kann M(A) = M(P) sein, aber M(A) = M(P) UND S(A) = S(P) ist doch schon viel unwahrscheinlicher.

Auszuschließen ist es aufgrund des Informationsverlustes jedoch nicht.
Im Grunde genommen ist die Verschlüsselung - und erst recht das Hashing - pure Stochastik.


AXMD - Sa 08.04.06 14:25

@Darkfire: und was hat dein Beitrag jetzt mit dem eigentlichen Thema zu tun :gruebel: ?

AXMD


nullplan001 - Sa 08.04.06 20:07

user profile iconzemy hat folgendes geschrieben:
Deine Prozedur hat wirklich ein geringes Sicherheitspotential. (Sorry) Ein einfaches XOR hält zwar erstmal ein ScriptKiddie davon ab, die Registry auszulesen. Wenn man sich aber länger damit beschäftigt (z.B. das Bitmuster anschaut), fällt es schnell auf....

Und was macht der Crack? Ich meine, der findet einen unsinigen Wert in der Registry und denkt, dass es sich um das verschlüsselte Passwort handelt. Stimmt aber nicht, es handelt sich um puren Stuss. Und selbst wenn er den Trick durchschaut, wie lange wird es brauchen, um das Format des verschlüsselten Passwortes festzustellen? (welches da ist: Länge der Verschlüsselungssequenz, Verschlüsselung, Schlüssel) Was hat man als Handle? Länge(Chiffre) = 2 * Länge(Klartext) + 1. Das ist nicht viel, aber man kommt drauf, wenn man einen aktiven Angriff startet.
user profile iconzemy hat folgendes geschrieben:
Für dich ist wohl eher was symetrisches geeignet. Die Frage ist blos, wie hebt man da den Key auf?

Meine Rede. Ich habe es ja so wie oben versucht, also Key in Chiffre eingearbeitet. Andere Möglichkeit wäre, beide getrennt abzuspeichern. Da kann man sich auch gleich in den Fuß schießen. Wie soll man das sicher machen? OK, nennen wir den Chiffretext "Key" und den Schlüssel "Password". Freude! Und irgendwann kriegt Kollege Hacker spitz, wie der Hase läuft. Verschiedene Schlüssel im Programm speichern und dann eine Method-Option in die Registry schreiben? Sodass ich den Key nirgends sichtbar abspeichere und ihn nur durch eine Nummer identifiziere? Auch schlecht, dass kann durchschaut werden -> dekompilieren -> Schlüssel rausfinden -> herzhaft lachen und E-Mail-Konten zum Spamen nutzen. Wie wäre es mit Method-Option als Key verkleidet? Wenn das geht, ist Kryptographie so wie aufräumen: 90% bestehen aus kaschieren und verstecken. :nut: Mir dröhnt der Schädel. Gibt es nicht irgendwas, sagen wir, zu 90% Sicheres, womit man ein Passwort so verschlüsseln kann, dass man es wieder entschlüsseln kann? Wie steht es mit Trap Doors? Wie schreibt man die (also jetzt nicht ortographisch sondern informatisch)?
Tschö,
nullplan


Delete - Sa 08.04.06 21:51

also die idee mit dem hash, find ich für gut. der one-way-algo ist doch ausreichend. wenn du dann deinen hash mit dem abgespeicherten verglichen hast, hast doch noch das orginal im zugriff. du musst also das passwd gar nicht mehr entschlüsseln sondern kannst es direkt an den server überleiten....

nimm einfach MD5 das ist denk ich für deine anforderungen mehr als ausreichend und codestrecken liegen hier zu hauf in der gegend rum... auch hier im forum....

noch viel spass und erfolg.


DaRkFiRe - Sa 08.04.06 23:21

Gehe direkt über 2 Antworten und rechtfertige Dich vor AXMD...

Also - es ginge wohl darum, ein Passwort zur Absicherung eines Programmes zu nutzen, dass mit Hilfe eines MD5 Algorithmus (One-Way) abgelegt werden sollte.

Ich hab nun nichts anderes gepostet, als dass man doch besser 2 Algorithmen benutzen sollte, da ich selbst schon zu meinem Passwort, zu dem ich ziemlich genau den MD5 Hash kenne ein anderes Passwort herausgefunden habe, das denselben Hash erzeugt! (Kollision!)
Also - 2 Algorithmen nehmen (MD5 + SHA1 [zum Beispiel] [+eigenen?]), damit die Sache sicherer wird.
Hier ist MD5 allein vielleicht sogar noch unsicherer, da es durch seine Byte-Länge von 16 auf sich aufmerksam macht. Man könnte vielleicht mit Padding arbeiten, um zu verwirren und zu verschleiern, dass es sich um einen MD5-Hash handelt. Natürlich hängt es davon ab, wie gespeichert wird.

Und da es hier ja um Sicherheit geht ( um eine Menge sogar, wenn es um das Speichern anderer [ und vor allem: mehrerer ] Passwörter geht ), dürfte mein Post doch von Relevanz sein, oder irre ich?


AXMD - Sa 08.04.06 23:24
Titel: Re: Verschlüsselungseffektivität überprüfen
user profile iconnullplan001 hat folgendes geschrieben:
ich bin dabei, ein Mailprogramm zu schreiben. Dazu muss man auch die Passwörter abspeichern (momentan bin ich noch bei Single Tasking, was bedeutet, dass ich momentan nur einen POP3- oder SMTP-Server bedienen kann.)


Nur mal um das klarzustellen: was soll gespeichert werden? Ein Passwort für das Programm oder ein Passwort zum Anmelden auf dem Server? Falls es letzteres ist, ist die Diskussion über einen Hash überflüssig, da der Mailserver mit dem Hash nichts anfangen kann... das habe ich vorhin gemeint.

AXMD


DaRkFiRe - Sa 08.04.06 23:28

Wenn es sich um das Speichern der Zugriffspasswörter zum Mailserver handelt - AXMD - dann hast Du natürlich Recht: hier müssen die Passwörter SELBST verschlüsselt werden, keine Frage.

Ich hatte mich auf MrSaint bezogen (okay, okay, nicht alles gelesen), der meinte, es müsse das Programm mit einem Passwort (ebenso?) geschützt werden.


AXMD - Sa 08.04.06 23:32

user profile iconDaRkFiRe hat folgendes geschrieben:
Ich hatte mich auf MrSaint bezogen (okay, okay, nicht alles gelesen), der meinte, es müsse das Programm mit einem Passwort (ebenso?) geschützt werden.


Was aber nichts weiter als eine Vermutung ist - es wird zumindest nicht explizit im Beitrag des Autors ersichtlich; daher würde ich vorschlagen, dass wir erst einmal warten, was der Autor des Beitrags dazu sagt - denn ohne jetzt sicher zu wissen, um welches Passwort es sich handelt, ist es nicht sehr sinnvoll weiterzudiskutieren, da die Anwendungsfälle hier doch zu unterschiedlich sind.

AXMD


DaRkFiRe - Sa 08.04.06 23:38

Ich hatte vor, meine Bedenken über die Verwendung (also mit einem [bekannten] Algorithmus, ohne jegliche Weiterverarbeitung) von Hashes zur Speicherung von Passwörtern äußern.

Demnach erst noch auf nullplan warten :)


zemy - So 09.04.06 00:59
Titel: Re: Verschlüsselungseffektivität überprüfen
user profile iconnullplan001 hat folgendes geschrieben:
Hi all,
ich bin dabei, ein Mailprogramm zu schreiben. Dazu muss man auch die Passwörter abspeichern (momentan bin ich noch bei Single Tasking, was bedeutet, dass ich momentan nur einen POP3- oder SMTP-Server bedienen kann.) Ich will mir jetzt nicht nachsagen lassen, ich schreibe die Passwörter einfach so in die Registry, also habe ich da ein Verfahren entwickelt. Wie kann ich die Effektivität meines Algorithmus überprüfen. Ich will ja nicht, das mein Programm kaum auf dem Markt ist, und schon ist die Verschlüsselung geknackt. Ich möchte vor allen Dingen auch die Resistenz gegen aktive Angriffe testen, also wo jemand haufenweise Passwörter verschlüsseln lässt und guckt, was damit passiert. Den Algorithmus zur Verschlüsselung werde ich verständlicherweise nicht posten.
Tschö,
nullplan


Ich bin mir ziemlich sicher, das nullplan001 Mehrere Passwörter meinte, die er verwenden will um sich an diversen Servern anzumelden. Aber bevor ich noch weiter durch die gegend zitiere und behaupte, das ich sowieso alles besser weiß, bring ich lieber ne neue Idee:

Wie währe es, aus einem (möglichst kryptischen) Passwort einen Key über irgend welche Hashs zu generieren. Somit hat man kein Problem mehr, wie man ihn aufhebt. Mann müsste eben nur möglichst zufälligen "Datenmüll" aus ca. 10 Zeichen saugen. ([sehr] Billige Variante: Zufallsgenerator als Seed mit nem Hashwert aus dem PW füttern)

@Nullplan: wegen dem XOR... Ich meinte nur, es währe das erste, wonach ich schauen würde, wenn ich auf eine schwache Verschlüsselung hoffe. Und auf mehr läufts nicht hinaus. Vor allem bei "Known Plaintext"...


nullplan001 - So 09.04.06 09:56

Erstaunlich, was einem die Leute so alles in den Mund legen... Um das jetzt mal klarzustellen: Mit Passwort meine ich natürlich die Konto-Passwörter für die Server. So, ich hatte jetzt vor, mir TrapDoors anzugucken, und was finde ich bei Wikipedia: Hashes arbeiten mit Info-Verlust, für TrapDoors musst du die Infos irgendwie zurückbehalten. Schön, sehr aufschlussreich. Ich glaub, ich probiere es mal mit Substitution. Mal gucken. Wie wäre es mit folgender Matrix:

Meine Matraze, äh..., Matrize
1:
2:
3:
4:
Großbuchstaben: Alphabet groß vorwärts = Alphabet klein rückwärts (A = z, B = y, etc.)
Kleinbuchstaben: Alphabet klein Hälftenweise vorwärts = Alphabet groß Hälftenweise rückwärts (a = M, b = L, ... , n = Z, o = Y, etc.)
Zahlen: 0 - 9 = 9 - 0 ( 0 = 9, 1 = 8, etc.)
Sonderzeichen (also der Rest): inc(Zeichen)

Kann man da drauf kommen? Mit dekompilieren / disassemblieren meine ich. Ich finde die Matrix ganz gut.
Tschö,
nullplan
P.S.: Ich habe jetzt mal die Matrize ausprobiert an CrypTool (wurde mir vom Infolehrer empfohlen). Ich habe nur die einfache Matrix genommen und siehe da: Die automatische Analyse kackt ab. Wenn der Text zu kurz ist, geht gar nicht mehr. Und da die wenigsten Passworte 100 Zeichen oder mehr umfassen, ist das schon mal ziemlich schwer zu entschlüsseln.


F34r0fTh3D4rk - So 09.04.06 12:10

ich denke mal deinen algo kann man durch disassambling rausbekommen, egal wie gut er ist :?


nullplan001 - So 09.04.06 18:24

In dem Fall bleibe ich bei der obigen Substitution. Danke und
Tschö,
nullplan


DaRkFiRe - So 09.04.06 19:05

user profile iconF34r0fTh3D4rk hat folgendes geschrieben:
ich denke mal deinen algo kann man durch disassambling rausbekommen, egal wie gut er ist :?


Ja, damit kann man so ziemlich alles rausbekommen - das ist die Crux der Seriellen Datenverarbeitung beim Computer.


Sirke - Do 13.04.06 14:32

Grundsätzlich ist das sichere Speichern von Passwörtern nicht möglich, da ein Schlüssel benötigt wird, der wiederum irgendwo gespeichert werden muss! Wenn man weiß, wo der Schlüssel gespeichert wurde und den Algo kennt (z.B. durch Disassambling), ist das Passwort unsicher!

Man könnte das ganze über einen Server abwickeln, auf dem die PWs gespichert sind! Dazu muss man "nur" die Authentizität sichergestellt werden! Dann kann ein PW leicht verschlüssel übertragen werden, z.B. über DH! Der Server ist ganz Sinnvoll, weil manm ja eh im Inet sein muss, weil man E-Mails abrufen möchte!

Vllt kann man bei dieser Möglichkeit weiter denken!

mfg Sirke


nullplan001 - Do 13.04.06 19:57

@Sirkes: Das ganze hat nur einen Haken: Ich kenne den Algo und habe Vollzugriff auf den Server. Würdest du jemandem Wildfremden dein Passwort anvertrauen wollen? In der Hoffnung, er missbraucht es nicht? Außerdem können Server gehackt werden, was wiederum die Passwörter freigeben würde, würde ich sie auf dem Server im Klartext speichern. Speichere ich sie verschlüsselt, wird das Programm zur Verschlüsselung mit gesaugt und disassembliert. Ergo: Es gibt keine Sicherheit im informatischen Bereich. Nur die Illusion davon. Wenn ich den Code z.B. in eine DLL auslagere und diese sonstwo sonstwie verstecke, ist der Dateiname samt Pfad auch aus dem Disassembler herauszufinden. Wenn man wirklich will, findet man sogar eine Umleitung über 50 verschiedene andere DLLs heraus.
Tschö,
nullplan


Sirke - Do 13.04.06 21:19

JEIN, die Passwörter lagern zwar auf einem Server, aber wenn du sie über eine ID speicherst und nur Prüfst, ob der Benutzer für die ID berechtigt ist, dann holt er sich das PW ohne das du weißt wofür es verwendet wird, weil du den Benutzernamen nicht weißt!
Es ist zwar ein Problem, aber was bringt dir ein Wörterbuch mit Passwörtern?!

ODER:
Du lagerst den Schlüssel für das Ver-/Entschlüsseln der Passwörter auf dem lokalen Rechner auf dem Server, sodass man sich den Schlüssel besorgt, und damit dann die Daten entschlüsselst!
So sollte es keine Probleme geben, weil du nur Zufallschlüssel hast, mit denen du NIX anfangen kannst, OHNE dass du dir die Daten vom lokalen Rechner holst, was sich dann aber Hacking nennt!


nullplan001 - Do 13.04.06 21:48

Hi all,
mal ne theoretische Frage: Ist es möglich, an eine DLL eine Funktion anzuhängen, ohne den genauen Quelltext der DLL zu kennen? Normalerweise würde man die Funktion ja ans Ende des Quelltextes schreiben und dann Compilieren. Bringt in meinem Fall nichts: Ich will die CRYPT32.DLL modifizieren. Sie soll so bleiben, wie sie ist, nur eine zusätzliche Funktion soll angehängt werden und natürlich exportiert werden. Geht das auch irgendwie zur Laufzeit? Sodass ich das in einem Installer besorgen kann? Schließlich will wohl niemand, dass ich auf seinem möglicherweise besserem System die Win2k-Variante draufpacke. Nachher braucht WinXP ein paar Funktionen aus der DLL, die die Win2k-Variante nicht hat, und der Anwender ist nach Installation meines mailprogs aufgeschmissen. (Wenns nur mit Compiler geht, ist auch nicht so schlimm. FreePascal ist nunmal "free", ich brauch bloß einen Eintrag in den Very Special Thanks der Credits zu packen). Wenn es noch unklar sein sollte: dieses dient der Spurenverwischung: Der Hacker kann der Spur meines Algos bis zur CRYPT32.DLL folgen. Die hat jedoch ein paar mehr Funktionen als nur die, die ich verwenden will. Gut der engagierte Hacker kommt auch hier weiter, aber eben nur der. (Wie der engagierte Hacker hier weiterkommt schreib ich besser nicht, sonst kommt auch der unengagierte drauf)
Nebenbei: Ich habe keinen Bock, eine riesige DLL nur aus Sicherheitsgründen zu schreiben.
Tschö,
nullplan


Diron - Do 20.04.06 21:05

user profile iconF34r0fTh3D4rk hat folgendes geschrieben:
ich denke mal deinen algo kann man durch disassambling rausbekommen, egal wie gut er ist :?


Nicht mal das bräuchte man! Eine einfache Häufigkeitsanalyse ermittelt binnen Sekunden das richtige Klartextalphabet! Substitution hat Maria Stuart verwendet, das ist veraltet und unsicher obendrein. Vigenere taugt hier auch nichts! Ich empfehle RSA o.ä.


Heiko - Do 20.04.06 21:41

Eigentlich ist es so ziemlich egal wie man das PW verschlüsselt. Wenn der PC etwas machen soll, ohne dass der Anwender ihn dazu auffordern muss, gibt es immer eine Möglichkeit das PW herauszubekommen. Nur wenn der Nutzter zusätzlich etwas machen muss, dass der PC anfängt etwas zu machen, ist etwas relativ sicher (bis auf wenn die Eingaben mit überwacht werden bzw. der Datenverkehr überwacht wird). Als Häcker würde ich mir nicht einmal die Mühe machen das Programm zu disassembilieren um den Schlüssel heraus zu finden, da man den Datenverkehr nur überwachen muss. Denn es ist Fakt, das Passwörter in den meisten Fällen unverschlüsselt an die Server versenden werden (FTP, e-mail, etc.). Die Verschlüsselung von PWs dient einfach nur dazu, um zu verhindern dass man ohne gewissen Aufwand an die Daten herankommt. Wer einen Angriff gezielt auf ein bestimmtes Programm macht, wird auch Erfolg haben. Die Schwierigkeuit liegt hierbei heut zu tage seltener an dem Häcken des Programms, sondern erst einmal das Hack-Proggi überhaupt auf den Rechner zu bekommen und es dann noch auszuführen. IMHO würde es reichen, 3-4 billige Verschlüsselungsverfahren übers PW laufen zu lassen. ...

mfg
Heiko


nullplan001 - Fr 21.04.06 18:35

user profile iconDiron hat folgendes geschrieben:
Eine einfache Häufigkeitsanalyse ermittelt binnen Sekunden das richtige Klartextalphabet!

Da mus ich dir leider wiedersprechen. Maria Stuart wollte keine Passwörter verschlüsseln, oder? Eine Häufigkeitsanalyse geht z.B. davon aus, dass 'e' der am häufigsten verwendete Buchstabe ist. Wäre mein Passwort jetzt 'nullplan', ist die Analyse schon wegen dieser Regel im Hintern. 3 'l', aber kein 'e'. Wer Passwörter in der Länge eines Buchtextes verwendet, hat meiner meinung nach 'nen Schaden (jeden morgen das gleiche Buch abtippen... :eyecrazy: Da muss man schon krank sein). Normalerweise sind Passwörter zwischen 4 und 10 Zeichen lang. Das reicht eindeutig nicht für eine Analyse.
Tschö,
nullplan