![[HaBo]](/styles/default/logoklein.png){kind=small}
Neues Verschlüsselungsprogramm (selbst gecodet)
- Themenstarter Tec
- Beginndatum
hi
@raz
das hört sich kompliziert an!!! kann man diese stat auswertung mit "normalen Windowsanwendungen" ermitteln!!!
Für mich hört es sich so an (so wie du geschrieben hast) das du dafür dir dein eigenes tool schreiben müsstest
ich bin zwar kein genie und kein guter progammierer (anfangsstadium) !! aber das hört sich verdammt schwer an ohne anhaltspunkt einen statistischen schlüssel zuermitteln.
Aber deine idee hat was!!!
Wie könnte man so etwas umgehen??
@raz
das hört sich kompliziert an!!! kann man diese stat auswertung mit "normalen Windowsanwendungen" ermitteln!!!
Für mich hört es sich so an (so wie du geschrieben hast) das du dafür dir dein eigenes tool schreiben müsstest
ich bin zwar kein genie und kein guter progammierer (anfangsstadium) !! aber das hört sich verdammt schwer an ohne anhaltspunkt einen statistischen schlüssel zuermitteln.
Aber deine idee hat was!!!
Wie könnte man so etwas umgehen??
ist ein guter ansatz aber man müsste zig-zehntausende texte vergleichen um einen mittelwert herauszufinden welcher halbwegs passen könnte um den addierten key-wert zu ermitteln.
angenommen es würden im jeden text nur ein zeichensatz von 256 zeichen benutzt werden, so müsste man um nur einen buchstaben entschlüsseln zu können, genau 256 texte abfangen, bei welchen auch der betroffene buchstabe unterschiedlich sein müsste. für den 2ten buchstaben käme diesselbe menge hinzu usw...
da windows aber unicode benutzt welcher aus 65536 zeichen besteht würde man also 65536 texte benötigen für ein zeichen usw..
man kann also anhand der schwankungsdiverenzen zwischen den einzelnen texten nur einen näherungswert ermitteln aber mehr auch nicht.
möglich wäre es also schon, aber es ist total unrealistisch.
wer also kleinere emails verschicken will (also unter 60000 zeichen bleiben) ist somit bestens bedient mit meinem proggi!
nachtrag:
werd jetzt ne version coden mit der man einen 1.000.000.000 grossen key erzeugen kann (bedankt euch bei raz
) um auch bücher krypten zu können!@Tec
Dann wirst Du einen bestimmten, internen Algo haben ?
Denn sonst koennte man ja den TExt nicht einfach so wieder
entschluesseln, was ja Sinn macht.
hmm
Wenn ich also einen Zahlenwert habe und der lautet
500, der koennte dann also irgendein Zeichen darstellen..
Wenn ich davon ausgehe, das Du einen Text verschluesselt hast
weiss ich ja schon mal den Mindestwert, der abzuziehen ist, da
der Buschstabenvorrat sich ja in einem bestimmten Rahmen bewegt
<- 128 ASCII...
ich muss sagen..das laesst mir keine Ruhe
)
:wq!
Dann wirst Du einen bestimmten, internen Algo haben ?
Denn sonst koennte man ja den TExt nicht einfach so wieder
entschluesseln, was ja Sinn macht.
hmm
Wenn ich also einen Zahlenwert habe und der lautet
500, der koennte dann also irgendein Zeichen darstellen..
Wenn ich davon ausgehe, das Du einen Text verschluesselt hast
weiss ich ja schon mal den Mindestwert, der abzuziehen ist, da
der Buschstabenvorrat sich ja in einem bestimmten Rahmen bewegt
<- 128 ASCII...
ich muss sagen..das laesst mir keine Ruhe
):wq!
nun die darzustellenden zeichen sind nur von windows begrenzt. windows nutzt aber unicode mit seinen 65536 zeichen.
der interne algo besteht besteht nur aus einer simplen addition. und zwar wird das aktuelle zu verschlüsselnde zeichenglied <Ak> mit dem codeglied <Bk> aus dem KEY addiert. die indexe von <Ak> und <Bk> sind diesselben. sie ändern sich nur wenn <Ak> grösser ist als <Bk> und somit der index von <Bk> wieder bei EINS anfangen muss. also wenn der key die grösse von 5000 hat und der zu verschlüsselnde text 10.000 zeichen enthält dann wird <Bk> wieder zu EINS wenn <Ak> bei 5001 angelangt ist (resp. bei 10.001, 15.001 etc..).
am ende bleibt in der ENDDATEI nur eine folge von zahlen <Ck> stehen wovon jedes Glied also die Summe aus <Aki> + <Bki> (i = index) ist.
der interne algo besteht besteht nur aus einer simplen addition. und zwar wird das aktuelle zu verschlüsselnde zeichenglied <Ak> mit dem codeglied <Bk> aus dem KEY addiert. die indexe von <Ak> und <Bk> sind diesselben. sie ändern sich nur wenn <Ak> grösser ist als <Bk> und somit der index von <Bk> wieder bei EINS anfangen muss. also wenn der key die grösse von 5000 hat und der zu verschlüsselnde text 10.000 zeichen enthält dann wird <Bk> wieder zu EINS wenn <Ak> bei 5001 angelangt ist (resp. bei 10.001, 15.001 etc..).
am ende bleibt in der ENDDATEI nur eine folge von zahlen <Ck> stehen wovon jedes Glied also die Summe aus <Aki> + <Bki> (i = index) ist.
A
antcool
Guest
In welcher Sprache hast du das gecodet Tec?
Delphi or VB!?
Delphi or VB!?
A
antcool
Guest
Voll fett ist das Prog!!
Aber die passwortabfrage kann man einfach umgehen(man benutzt keins(Passwort) oder ein will kürliches um die Passwort abfrage zu umgehen!!)
Das ist der einzige Bug denn ich finden konnte !!
Aber du mustt mir mal den Verschlüsselungsalgo. von Prog (intern!!) erklären!
Aber die passwortabfrage kann man einfach umgehen(man benutzt keins(Passwort) oder ein will kürliches um die Passwort abfrage zu umgehen!!)
Das ist der einzige Bug denn ich finden konnte !!
Aber du mustt mir mal den Verschlüsselungsalgo. von Prog (intern!!) erklären!
ist kein bug - ist ne sicherheitsmassnahme!!
hehe das ist kein bug! geh mal in die mandantenverwaltung und schau dir an was da steht - entschlüsselter text mit dem falschen passwort. *g*
ich hab das extra so gemacht, weil normalerweise wird das eingegebene passwort auf die richtigkeit überprüft, weshalb also das richtige passwort irgendwo vorhanden sein muss und somit ermittelt werden kann. mein proggi überprüft überhaupt nicht ob das passwort richtig/falsch ist, es nimmt es einfach als gegeben an und entschlüsselt nach dem key-verfahren die mandantendatei. ob das ergebnis dann stimmt sieht der anwender sobald er mit XTC arbeiten muss (ooops, das hinterlegte passwort bei mandant %$§$% lautet ja %$/§$ - ob das richtig ist? ).
hehe das ist kein bug! geh mal in die mandantenverwaltung und schau dir an was da steht - entschlüsselter text mit dem falschen passwort. *g*
ich hab das extra so gemacht, weil normalerweise wird das eingegebene passwort auf die richtigkeit überprüft, weshalb also das richtige passwort irgendwo vorhanden sein muss und somit ermittelt werden kann. mein proggi überprüft überhaupt nicht ob das passwort richtig/falsch ist, es nimmt es einfach als gegeben an und entschlüsselt nach dem key-verfahren die mandantendatei. ob das ergebnis dann stimmt sieht der anwender sobald er mit XTC arbeiten muss (ooops, das hinterlegte passwort bei mandant %$§$% lautet ja %$/§$ - ob das richtig ist?
). gerne, wenn wir uns mal im IRC sehen.
so jetzt war mir so langweilig dass ich einfach mal ein bisschen probiert hab....
1. keine 2 nuller zwischen die zahlen, das verwirrt niemanden mehr und ist höchstens als hackit wie auf newbie-network.de zu gebrauchen
3. hmmm
ich hab ne klartext datei mit dem buchstaben "a".
dann hab ich das mal mit dem Passwort "aaa" und dem mit dem Pass "bbb" verschlüsselt.
Ergebnis: Das mit dem bbb verschlüsselte war bloss eine nummer höher. damit ist es ne vigenere oder ne abart davon....
ich schlag dir ja deine redlichen Absichten nicht aus noch stell ich sie in Frage, aber du hast einfach grundlegende Prinzipien dabei missachtet /nicht gewusst.
Aber gui und doku ist cool.
Wenn du willst kann ich ja ein paar tips hierreinschreiben was zu verbessern wäre.
es wird da übrigens wo auf sourceforge ein tool gebaut, bei dem genau solche verfahren viel leichter gebrochen werden können. also würde ich dir raten, dass du dir einen richtigen Algo ankuckst, weil das Programm bis auf das Verfahren selbst gut ist. richtig sorgfältig programmiert
1. keine 2 nuller zwischen die zahlen, das verwirrt niemanden mehr und ist höchstens als hackit wie auf newbie-network.de zu gebrauchen
3. hmmm
ich hab ne klartext datei mit dem buchstaben "a".
dann hab ich das mal mit dem Passwort "aaa" und dem mit dem Pass "bbb" verschlüsselt.
Ergebnis: Das mit dem bbb verschlüsselte war bloss eine nummer höher. damit ist es ne vigenere oder ne abart davon....
ich schlag dir ja deine redlichen Absichten nicht aus noch stell ich sie in Frage, aber du hast einfach grundlegende Prinzipien dabei missachtet /nicht gewusst.
Aber gui und doku ist cool.
Wenn du willst kann ich ja ein paar tips hierreinschreiben was zu verbessern wäre.
es wird da übrigens wo auf sourceforge ein tool gebaut, bei dem genau solche verfahren viel leichter gebrochen werden können. also würde ich dir raten, dass du dir einen richtigen Algo ankuckst, weil das Programm bis auf das Verfahren selbst gut ist. richtig sorgfältig programmiert
Diagramm!
also die 2 nullen sind keine dummys, die habe ich eingebaut da der key auch werte erzeugen könnte die 5-stellig sind. außerdem musste ich unicode beachten. das proggi geht davon aus das immer 5 stellen eine zahl ergeben, sollte also z.b. ascii-wert + key zusammen 4567 ergeben, so wird vorne ein null hinzugefügt. das ist ein programmtechnischer ablauf und keine verwirrungstaktik. wer würde denn schon auf sowas reinfallen?
so ist ja mein simpler algo aufgebaut. er addiert zu 'a' den wert von 'b'. mein key besteht aber nicht nur aus den werten lauter 'b's sondern aus dem bereich von 1 bis 99.999, wo für das erste zeichen also z.b. 20, fürs 2te 555, fürs 3te 54663, fürs 4te 80122, fürs 5te 1234 etc.. genommen wird.
ein statischer key wird umgehend geknackt, ein variabler, bei dem für jedes zu verschlüsselnde zeichen ein anderer wert genommen wird, eine sisyphus-arbeit ist.
das passwort wird in meinem proggi wie ein key behandelt, d.h. es wird in seine bestandteile zerlegt und ebenfalls auf den ascii wert addiert.
zum besseren verständnis habe ich ein diagramm erstellt.
es wurde hier das wort "Hallo" verschlüsselt (unterer wert des diagramms). dann kommt das passwort (mittlerer wert) und schlieslich der key (oberer wert). ist das passwort 5 stellen lang, so fängt es am 6 buchstaben an sich zu wiederholen. genauso ist es mit dem key.
also die 2 nullen sind keine dummys, die habe ich eingebaut da der key auch werte erzeugen könnte die 5-stellig sind. außerdem musste ich unicode beachten. das proggi geht davon aus das immer 5 stellen eine zahl ergeben, sollte also z.b. ascii-wert + key zusammen 4567 ergeben, so wird vorne ein null hinzugefügt. das ist ein programmtechnischer ablauf und keine verwirrungstaktik. wer würde denn schon auf sowas reinfallen?
so ist ja mein simpler algo aufgebaut. er addiert zu 'a' den wert von 'b'. mein key besteht aber nicht nur aus den werten lauter 'b's sondern aus dem bereich von 1 bis 99.999, wo für das erste zeichen also z.b. 20, fürs 2te 555, fürs 3te 54663, fürs 4te 80122, fürs 5te 1234 etc.. genommen wird.
ein statischer key wird umgehend geknackt, ein variabler, bei dem für jedes zu verschlüsselnde zeichen ein anderer wert genommen wird, eine sisyphus-arbeit ist.
das passwort wird in meinem proggi wie ein key behandelt, d.h. es wird in seine bestandteile zerlegt und ebenfalls auf den ascii wert addiert.
zum besseren verständnis habe ich ein diagramm erstellt.
es wurde hier das wort "Hallo" verschlüsselt (unterer wert des diagramms). dann kommt das passwort (mittlerer wert) und schlieslich der key (oberer wert). ist das passwort 5 stellen lang, so fängt es am 6 buchstaben an sich zu wiederholen. genauso ist es mit dem key.