| Autor |
Beitrag |
Florens
      
Beiträge: 32
|
Verfasst: So 31.10.10 14:39
Hallo liebe community,
ich bin neu hier und hoffe, dass ihr mir helfen könnt. Zurzeit versuch ich mich an RSA ver- und entschlüsselung, aber bleiben wir erstmal bei der Verschlüsselung. Hier der Algorithmus mit dem ich es bisher probiert habe: 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:
| procedure TRSA.Button1Click(Sender: TObject);
var i, j, B, RSAC: Integer; Buchstabe: Char; BB: Extended;
begin PublicKey:=StrToFloat(Edit3.Text); BB:=1; Edit8.visible:=true; label10.Visible:=true; label11.visible:=true; label11.Caption:='';
for i:=1 to 2 do begin BB:=1; Buchstabe:=Edit7.Text[i]; B:=Ord(Buchstabe);
for j:=1 to Trunc(PublicKey) do begin BB:=BB*B; end;
RSAC:=trunc(BB) mod(n); Label11.Caption:=Label11.Caption+IntToStr(RSAC)+' '; end;
Edit8.Text:=Label11.Caption;
end; |
(Der Auszug gehört nicht zum gesamten Algorithmus).
Nun ist mein Problem, dass Delphi sobald der Public Key größer als 15 ist immer die Fehlermeldung kommt, dass die rechnung keine gültige Gleitkommaoperation wäre. Ich vermute das Die Zahl einfach zu groß wird und Extended dafür nicht mehr ausreicht. Schließlich gehen alle Zahlen darunter wunderbar.
Meine Frage wäre, ob es einen Datentyp gibt, der einen größeren Zahlenbereich abdeckt als Real oder Extended schließlich schafft der Windows-Calculator solche Rechnungen auch ohne Probleme.
Einloggen, um Attachments anzusehen!
|
|
jaenicke
      
Beiträge: 19346
Erhaltene Danke: 1754
W11 x64 (Chrome, Edge)
Delphi 12 Pro, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: So 31.10.10 14:45
Hallo und
Florens hat folgendes geschrieben : | | schließlich schafft der Windows-Calculator solche Rechnungen auch ohne Probleme. |
Der benutzt auch keine Standarddatentypen. Das wirst du schon selbst berechnen müssen.
Es gibt aber auch fertige Quelltexte für größere Zahlen.
|
|
Florens 
      
Beiträge: 32
|
Verfasst: So 31.10.10 14:55
jaenicke hat folgendes geschrieben : | Der benutzt auch keine Standarddatentypen. Das wirst du schon selbst berechnen müssen.  |
Und wie machen das dann Leute die ganze Texte mit 1024bit Schlüsseln verschlüsseln? die werden doch auch nicht jeden einzelnen Buchstaben durchrechnen...
Danke für die Antwort aber so schnell geb ich nciht auf...sitz seit gestern an diesem Programm und wills jetzt zuende führen. Gibt es eine möglichkeit mit meinem Programm auf den Calculator zuzugreifen und dann einfach das Ergebnis rauszukopieren?
|
|
jaenicke
      
Beiträge: 19346
Erhaltene Danke: 1754
W11 x64 (Chrome, Edge)
Delphi 12 Pro, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: So 31.10.10 14:58
Florens hat folgendes geschrieben : | | die werden doch auch nicht jeden einzelnen Buchstaben durchrechnen... |
Doch, so habe ich das gemacht.
Es gibt aber wie gesagt auch einiges an fertigem Code dazu.
|
|
platzwart
      
Beiträge: 1054
Erhaltene Danke: 78
Win 7, Ubuntu 9.10
Delphi 2007 Pro, C++, Qt
|
Verfasst: So 31.10.10 15:13
Such mal nach Bignum z.B.
_________________ Wissenschaft schafft Wissenschaft, denn Wissenschaft ist Wissenschaft, die mit Wissen und Schaffen Wissen schafft. (myself)
|
|
Gausi
      
Beiträge: 8554
Erhaltene Danke: 481
Windows 7, Windows 10
D7 PE, Delphi XE3 Prof, Delphi 10.3 CE
|
Verfasst: So 31.10.10 15:15
Nebenbei wird RSA (und viele andere Verschlüsselungsverfahren) mit Extended oder anderen Gleitkommatypen sowieso nicht funktionieren. Das sind Ganzzahl-Algorithmen. 
_________________ We are, we were and will not be.
|
|
hathor
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: So 31.10.10 15:20
|
|
Florens 
      
Beiträge: 32
|
Verfasst: So 31.10.10 15:22
|
|
Gausi
      
Beiträge: 8554
Erhaltene Danke: 481
Windows 7, Windows 10
D7 PE, Delphi XE3 Prof, Delphi 10.3 CE
|
Verfasst: So 31.10.10 15:28
Int64 kann auch nicht größere Zahlen verwalten als Extended. 
_________________ We are, we were and will not be.
|
|
hathor
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: So 31.10.10 15:29
@Florens
Was Du machst, ist total unsinnig.
Das ist nicht verschlüsselt, sondern ausgetauscht...
|
|
Florens 
      
Beiträge: 32
|
Verfasst: So 31.10.10 15:31
|
|
Gausi
      
Beiträge: 8554
Erhaltene Danke: 481
Windows 7, Windows 10
D7 PE, Delphi XE3 Prof, Delphi 10.3 CE
|
Verfasst: So 31.10.10 15:36
Die falschen Zahlen kommen durch den Überlauf. Wenn du bei den 2^63-1 angekommen bist, und noch eins draufaddierst, fängt Int64 wieder von vorne an zu zählen, also bei -2^63.
_________________ We are, we were and will not be.
Für diesen Beitrag haben gedankt: Florens
|
|
Gammatester
      
Beiträge: 328
Erhaltene Danke: 101
|
Verfasst: So 31.10.10 15:44
Florens hat folgendes geschrieben : | | Und wie machen das dann Leute die ganze Texte mit 1024bit Schlüsseln verschlüsseln? die werden doch auch nicht jeden einzelnen Buchstaben durchrechnen... |
Dein Code hat mindestens drei Probleme:
Delphi-Quelltext 1: 2: 3:
| for j:=1 to Trunc(PublicKey) do begin BB:=BB*B; end; |
Hier wird zuerst BB^Publickey berechnet und dann modulo-reduziert, das ergibt dann die zu großen Zahlen. Eine erste Verbessung ist, sofort nach jeder Multiplikation zu reduzieren.
Delphi-Quelltext 1: 2: 3:
| for j:=1 to Trunc(PublicKey) do begin BB:=BB*B mod n; end; |
Ein weiteres Problem wird sein, daß das für größere Zahlen viel zu lange dauert. Dafür gibt es dann die schnelle binäre modulare Exponentation, die mit maximal 2*(Anzahl Bits in Publickey) Multiplikationen auskommt (statt mit PublicKey).
Das dritte Problem, ist die reine Bitgröße. Alles kleiner gleich 64 Bit ist völlig trivial, einigermaßen sicher sind 1024 Bits besser etwas mehr.
Bei meinen Pascal- RSA-Funktionen findest Du einiges implementiert, inclusive Beispieltestprogramme für die bekannten Angriffe.
Für diesen Beitrag haben gedankt: Florens
|
|
Florens 
      
Beiträge: 32
|
Verfasst: Mo 01.11.10 22:56
WUUUUUUUUUUUUUUUUUUUT!!! Ich hab gerade mal nen rechner geschrieben der 70^1024 locker und schnell rechnet. In meinem RSA verschlüsselungsalgorithmus muss ein anderer Fehler liegen, sodass mir Delphi sagt es sei eine ungültige Gleitkommaoperation >.<. (Mein rechner ist im Anhang genauso).
Der Rechner rechnet nach dem selben Prinzip wie der RSA Algorithmus:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17:
| procedure TForm1.Button1Click(Sender: TObject); var i,x,y :integer; z: Extended;
begin Memo1.Lines.Clear; x:=StrToInt(Edit1.Text); y:=StrToInt(Edit2.Text); z:=1;
for i:=1 to y do begin z:=z*x; Memo1.Lines.Add(FloatToStr(z)); end;
Edit3.Text:=FloatToStr(z); end; |
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:
| procedure TRSA.Button1Click(Sender: TObject); var i, j, B, RSAC, x: Integer; Buchstabe: Char; BB: Extended; begin PublicKey:=StrToFloat(Edit3.Text); BB:=1; x:=length(Edit7.Text); Edit8.visible:=true; label10.Visible:=true; label11.visible:=true; label11.Caption:='';
for i:=1 to x do begin BB:=1; Buchstabe:=Edit7.Text; B:=Ord(Buchstabe);
for j:=1 to Trunc(PublicKey) do begin BB:=BB*B; end;
RSAC:=trunc(BB) mod(n); Label11.Caption:=Label11.Caption+IntToStr(RSAC)+' '; end;
Edit8.Text:=Label11.Caption;
end; |
Trunc entfernen hat nichts gebracht. ebenfalls mein Verdacht, dass mod mit dem E bei extended nciht klarkommt (4,7827E15) ist ebenfalls falsch nachdem der Rechner das rechnen konnte...)
Einloggen, um Attachments anzusehen!
|
|
Flamefire
      
Beiträge: 1207
Erhaltene Danke: 31
Win 10
Delphi 2009 Pro, C++ (Visual Studio)
|
Verfasst: Mo 01.11.10 23:43
Dann solltest du mal lesen, was hier geschrieben wird: RSA ist GANZzahlig. Warum also Floating point verwenden? Gibt nur hässliche Rundungsfehler. Einziger Vorteil ist der etwas größere Zahlenbereich. Aber halt ungenau!
Und sich einzubilden damit 70^1024 exakt zu berechnen ist quark...
BigNum ist eine Lösung, die das kann.
|
|
BenBE
      
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: Di 02.11.10 04:53
Zumal BigNum das auch recht schnell rechnen kann - und vor allem korrekt. Und die Modulo-Operationen sind dort beim Potentieren sogar gleich in optimierter Form drinnen, so dass das nicht unnötig bremst.
Gib uns doch mal bitte dein vollständiges "exaktes" Ergebnis für 70^1024.
Zur Kontrolle: Die letzten Stellen, die nicht 0 sind: 4401
_________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
Florens 
      
Beiträge: 32
|
Verfasst: Di 02.11.10 20:46
Flamefire hat folgendes geschrieben : | Dann solltest du mal lesen, was hier geschrieben wird: RSA ist GANZzahlig. Warum also Floating point verwenden? Gibt nur hässliche Rundungsfehler. Einziger Vorteil ist der etwas größere Zahlenbereich. Aber halt ungenau!
Und sich einzubilden damit 70^1024 exakt zu berechnen ist quark...
BigNum ist eine Lösung, die das kann. |
1. Habs mit meinem Rechner probiert und mit dem Windows Calculator überprüft...Die Ergebnisse für modolu sind identisch also nix da mit Rundungsfehlern (Extended macht ja 19 Stellen nach dem Komma also schätz ich mal schreibt der das nur Beispielsweise 1,[16Stellen]E15 wenn man die Zahl in einen String konvertiert. Die richtige Zahl scheint das Programm aber im Cache zu behalten.
mal nen Beispiel: Mein Rechner->70^1024=2,40100450320503E1889 ->2,40100450320503E1889 mod 187=Okaaay gestern hats noch geklappt jetzt gibt er mir hier ebenfalls ungültige
gleitkommaoperation aus....Der Windows Calculator sagt es soll 69 rauskommen
2. Wie verwende ich BigNum? Ist das ein Datentyp? Bei Google kommt immer nen Rechner den man sich runterladen kann und irgendwelche Mailinglists etc.
3. Das Beispiel bei erstens ist wirklich seltsam...hab gerade bei meinem Rechner sowohl k als auch f mal als Extended gesetzt und 2^50 was ebenfalls mit nem E ausgegeben wird macht der modolu nur die monströse 70^1024 Zahl nicht
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9:
| procedure TForm1.Button2Click(Sender: TObject); var k,f: Extended; begin f:=StrToFloat(Edit5.Text); Memo1.Lines.Add(FloatToStr(f)); k:=trunc(z) mod(trunc(f)); Edit6.Text:=FloatToStr(k); end; |
4. BenBE hat folgendes geschrieben : |
Gib uns doch mal bitte dein vollständiges "exaktes" Ergebnis für 70^1024.
Zur Kontrolle: Die letzten Stellen, die nicht 0 sind: 4401 |
Wie soll ich das machen wenn er die letzten Zeilen vor mir versteckt mit nem E
|
|
jaenicke
      
Beiträge: 19346
Erhaltene Danke: 1754
W11 x64 (Chrome, Edge)
Delphi 12 Pro, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Di 02.11.10 20:54
Florens hat folgendes geschrieben : | | Wie soll ich das machen wenn er die letzten Zeilen vor mir versteckt mit nem E |
die versteckt er nicht, die hat er schlicht nicht. Das ist eben die interne Darstellung von Gleitkommazahlen...
Eine gewisse Anzahl Stellen und den Rest dann als "Anzahl Nullen", sprich der Exponent.
|
|
Flamefire
      
Beiträge: 1207
Erhaltene Danke: 31
Win 10
Delphi 2009 Pro, C++ (Visual Studio)
|
Verfasst: Di 02.11.10 21:02
richtig. 1,265E12 heißt 1,265*10^12
und BigNum ist eine Klasse/Unit, die du hier im Forum findest. Ist von BenBE, jaenicke und mir (in der Reihenfolge)
|
|
Florens 
      
Beiträge: 32
|
Verfasst: Di 02.11.10 21:02
jaenicke hat folgendes geschrieben : | Florens hat folgendes geschrieben : | | Wie soll ich das machen wenn er die letzten Zeilen vor mir versteckt mit nem E | die versteckt er nicht, die hat er schlicht nicht. Das ist eben die interne Darstellung von Gleitkommazahlen...
Eine gewisse Anzahl Stellen und den Rest dann als "Anzahl Nullen", sprich der Exponent. |
Mal der Versuch wiedermal mit meinem Rechner: 17^13=9,90457803290594E15
9,90457803290594E15/17(sollte j eine ganze Zahl rauskommen)=582622237229761 (was der Fall ist)
zum Bignum-> Sooo hab jetzt jemanden gefunden der ebenfalls an RSA gescheitert war aber mit BigNum offensichtlich gut geholfen wurde( www.delphi-forum.de/...mp;highlight=bignum). Ich versteh nur noch nicht, wie ich Units in Delphi einfüge und wozu diese überhaupt da sind. Soweit sind wir in Info noch nicht. Morgen hab ich wieder Info dann werd ich einfach mall meinen Lehrer zu BigNum und Units ausquetschen. Insofern 51 92 66 112 84 76 119 142 126 76 92 48 48 76 144 96 84 76 30 96 48 119 84 (Private Key zum entschlüsseln-> (23|187))
Zuletzt bearbeitet von Florens am Di 02.11.10 21:15, insgesamt 1-mal bearbeitet
|
|