eine Variable bei jedem Durchlauf ändern, aber immer anders?

[malo]

Zitat von Niels:

Zitat von malo:

Und dein komischer Satz ist echt komisch, den kapier ich nämlich nicht

Ok, da is auch n Rechtschreibfehler drin gewesen

Ich hab nur gemeint, dass deine Variable Aenderung immer größer wird. Du addierst zwar dazu und ziehst auch wieder ab, aber was du abziehst ist weniger, als das was du dazu addierst.

MfG Niels

Achso. Ja, das war eigentlich auch beabsichtigt, weil ich ja hinterher auch mal die ganzen Case-Anweisungen wiederholen wollte und keine Regelmäßigkeiten wollte. Wenn nun zuerst bei 0 gestartet wird und später bei 5 ist es schwieriger, den Code "von Hand" zu entschlüsseln, weil halt keine Regelmäßigkeiten auftreten

//edit: aber ich hab ja nur ein "a" entschlüsseln wollen, und da kommt direkt ein 7-Stelliger Code

[Niels]

Naja du sagtest, dass es kein unknackbares Verfahren werden soll, andererseits willst du es doch möglichst sicher.
Sobald jemand weiß, wie dein Verfahren funktioniert und das sollte ja jeder, der es benutzt, ist diese Verschiebung sowieso kein Hindernis mehr beim knacken. und diese Verschiebung um 5 ist ja auch wieder eine Regelmäßigkeit, weil es ja immer 5 mehr werden .

Zu deinem a:
setzt du am Anfang Aenderungszaehler und Aenderung auf 0? Sonst haben die zufällige Werte (naja nicht ganz zufällig, aber halt das was an der Adresse, wo sie hinzeigen grad im RAM steht)!

MfG Niels

[malo]

Zitat von Niels:

Zu deinem a:
setzt du am Anfang Aenderungszaehler und Aenderung auf 0? Sonst haben die zufällige Werte (naja nicht ganz zufällig, aber halt das was an der Adresse, wo sie hinzeigen grad im RAM steht)!

AenderungsZahler hab ich auf 0 gesetzt, Aenderung nicht, weil es ja eine lokale Variable ist. Und ich dachte halt, integer-Variablen ohne Wert sind immer 0


Aber funktioniert das sogar, danke!

//edit: Wegen Sicherheit: Ja, ich versuche halt das System, was ich mir "ausgetüftelt" habe, möglichst sicher zu machen. Ich werde aber (jedenfalls in absehbarer Zeit) kein neues System programmieren, auch wenn das sicherer ist

[SirThornberry]

Zitat von Binärbaum:

Man könnte es so probieren:

Delphi-Quellcode:

var
 mein_text: string;//Original
 neuer_Text: string;//Verschlüsselt

...

neuer_text:=mein_Text; //Verschlüsselter Text initialisieren
for i:= 1 to Length(mein_Text) do begin
 neuer_Text[i]:= Chr(Ord(mei_text[i])+ (i mod 25));
end;

Hallo??? So kannst du den verschlüsselten Text schon fast in den Müll werfen. angeommen mein Zeichen hat den Ascii-Wert 254 und i ist 3, dann würde bei würde bei der "254 + 3" gerechnet werden was "257" ergibt. Und wenn du das mit "chr" wieder zurück schreibst kommt was falches raus weil es kein ascii-wert "257" gibt. Auf grund eines Überlaufes würd vermutlich dann der Ascii-Wert "1" sein und nicht wie es laut berechnung sein müsste "257"

[Niels]

Zitat von SirThornberry:

Zitat von Binärbaum:

Man könnte es so probieren:

Delphi-Quellcode:

var
 mein_text: string;//Original
 neuer_Text: string;//Verschlüsselt

...

neuer_text:=mein_Text; //Verschlüsselter Text initialisieren
for i:= 1 to Length(mein_Text) do begin
 neuer_Text[i]:= Chr(Ord(mei_text[i])+ (i mod 25));
end;

Hallo??? So kannst du den verschlüsselten Text schon fast in den Müll werfen. angeommen mein Zeichen hat den Ascii-Wert 254 und i ist 3, dann würde bei würde bei der "254 + 3" gerechnet werden was "257" ergibt. Und wenn du das mit "chr" wieder zurück schreibst kommt was falches raus weil es kein ascii-wert "257" gibt. Auf grund eines Überlaufes würd vermutlich dann der Ascii-Wert "1" sein und nicht wie es laut berechnung sein müsste "257"

Da die ersten 32 ASCII-Zeichen Steuerzeichen sind, würde ich einfach '- (i mod 25)' anstatt '+ (i mod 25)' nehmen. Damit bekommst du keine Probleme. Wenn du natürlich mehr als i mod 32 hast, wird's dann problematisch, da müsste man dann was ändern.

[SirThornberry]

@niels: So würde es natürlich für einfache Texte funktionieren. Aber meist ist es so das der Programmierer, nach dem es mit einfachtem Text funktioniert, das ganze mit allen möglichen Datein versucht zum Beispiel mit bildern um diese zu verschlüsslen. Und spätestens das funktioniert das ganze dann irgendwann wieder nicht weil auch zeichen mit Ascii-Wert < 32 verwendet werden.

[Binärbaum]

@Niels, @Thornberry:
So kann man es natürlich auh machen. Ich bin allerdings davon ausgegangen, dass die Bereichsüberprüfung ausgeschaltet ist (per Compileroption bzw. Präprozessor). Dann würde man einfach wieder bei 0 anfangen, wenn man den zulässigen Bereich verlässt. Da ein Byte ja nur von 0-255 geht, würde ein Ordinalwert von 257 dann wieder als 2 interpretiert und man hätte keine Probleme (abgesehen davon, dass man dann in den Steuerzeichen ist).

MfG
Binärbaum

[SirThornberry]

257 als 2?
Ich hätte gedacht als 1 weil es ja bei 0 wieder los geht.
Also 255 + 1 = 256/0
und 256 + 1 = 257/1

[Binärbaum]

Ja klar, war mein Fehler.
Natürlich ist die 257 dann eine 1 und keine 2. Aber das spielt ja kaum eine Rolle, Hauptsache das Programm kommt damit zurecht. Selbst wenn es eine 2 wäre, würde es durchs Entschlüsseln wieder auf die richtige zahl und das richtige Zeichen kommen.

MfG
Binärbaum