mir reicht's! Kryptostream muß her!
-
Warum nicht einfach von basic_istream ableiten - hab zwar keine Ahnung von Kryptographie, aber:
template <class Typ , class Traits = std::char_traits <Typ> > class crypto_istream : public std::basic_istream < Typ , Traits > { // Weniger sinnvoll: void decrypt (...); // Vielleicht interessanter: friend istream & operator >> ( ... ); } template < ... > class crypto_ostream : public std::basic_ostream < ... > { friend ostream & operator << ( ... );Die Idee könnte man insofern erweitern, dass man komplett auf die Ableitung verzichtet und einfach crypt und decrypt als neue Manipulatoren verwendet, also ala:
cout << crypt << "Verschlüssle diesen Text!";MfG SideWinder
-
Please delete.
MfG SideWinder
[ Dieser Beitrag wurde am 16.04.2002 um 19:32 Uhr von SideWinder editiert. ]
-
Hier mal mein vorläufiges Konzept für den Einbau:
ostream & crypt ( ostream & rStream ) { // Arbeiten am Stream, wie zum Beispiel: rStream.write ( "Side" , 7 ); return ( rStream ); } // Bei Aufruf von cout << crypt << "Winder"; // bekommt man am Bildschirm SideWinder zu sehen.Den Algo müssen dann eben die Krypto-Freaks einbauen.
MfG SideWinder
-
Naja, der Manipulator brauch noch ein int-Argument für den Schlüssel. Wäre ja nicht sinnvoll, wenn alle Leute mit dem gleichen Schlüssel verschlüsselten.
-
Hallo,
der Mann, die Frau für a) sollte bedenken, dass es eine Aufgabenteilung bei den C++-Streams gibt.
Die low-level-Funktionalität gehört meiner Meinung nach eindeutig in eine von std::streambuf abgeleitete Klasse.Bsp für sinnvolle Eigenbau-Streams gibt's zu hauf (ich kenne z.B. Perlstreams, Socket-Streams, Curses-Streams, Verzeichnis-Browse-Streams usw.). Solche Beispiele können bei der Implementation sicher hilfreich sein.
[ Dieser Beitrag wurde am 16.04.2002 um 20:07 Uhr von HumeSikkins editiert. ]
-
Logisch, aber jetzt wirds a bissal kompliziert - vielleicht kann da wer anderer mit einer neueren Version herhalten, ich schaffs nur mit dem veraltetem Header <iomanip.h> und der Hilfe der MSDN:
ostream & cryptfunc ( ostream & rToCrypt , int Key ) { // Arbeiten am Stream return ( rToCrypt ); } OMANIP(int) crypt ( int Key ) { return ( OMANIP(int) ( cryptfunc , Key ); } cout << crypt (KEY) << "SideWinder";MfG SideWinder
-
Das logisch war auf DoktorProkts Antwort bezogen - Hume hat dazwischengepostet images/smiles/icon_redface.gif images/smiles/icon_wink.gif.
Weil Hume schon mal anwesend ist: Wie bau ich mir mit der neuen <iomanip> einparametrige Manipulatoren?
MfG SideWinder
-
Hi!
Original erstellt von volkard:
Hey, Leute!
Nimmt er Blasefisch oder sowas, dann braucht er erstmal drei Wochen, bis er drin ist.
Never! - Es sei denn, er ist sehr stümperhaft eingestellt. Blowfish hat einen variabele Schlüsselbreite bis zu 448 Bit und verwendet 16 Runden XOR, variabelen S-Boxen u. Additionen. - Ist übrigs lizenzpflichtig.
**
klassiker wie Caesar, IDEA, RSA, DES udn was man alles im Netz so finden kann, einfach mal einbauen.
Müßte eigentlich nen Heidenspaß machen. Außerdem wär das Produkt ziemlich brauchbar.**
DES hat ein 56 Bit-Schlüssel. Heute maximal 5h -'brute force' - deshalb wurde die alte 'Feistel' bereits 1998 aus dem Verkehr gezogen , verwendet wenigsten TDEA oder besser AES. Ausgehend von RSA hat sich heute RC5 durchgesetzt. Ok, RSA ist public-source und RC5 ist lizenzpflichtig. TDEA und IDEA sind Bestandteil von PGP, vielleicht kann man die direkt nutzen. Spaß machen Verschlüsselungsalgorithmen nicht. Sie treiben dich in den Wahnsinn, glaub mir... images/smiles/icon_cool.gifAber laßt euch abschrecken.. images/smiles/icon_biggrin.gif
P84
-
Die low-level-Funktionalität gehört meiner Meinung nach eindeutig in eine von std::streambuf abgeleitete Klasse.
Ähm, könnten wir die Krypto-Dinge mal Lowlevel nennen und immer Bufferweise krypten lassen? Falls ja, wäre das glaub ich recht geil, weil man keinen einzigen op>> antatschen müßte.
-
Original erstellt von Prof84:
**Hi!Aber laßt euch nicht abschrecken.. images/smiles/icon_biggrin.gif
P84**
-
Wie bau ich mir mit der neuen <iomanip> einparametrige Manipulatoren?
Es gibt keinen standardisierten Weg um Manipulatoren die Parameter erwarten zu implementieren.
Hier ein möglicher Umweg:
struct ManipWithArgument { ManipWithArgument(int i, double d); }; std: :DeinStream& operator<<(DeinStream& o, ManipWithArgument Manip) { // mach was mit o return o; } // irgendwo CryptStream << ManipWithArgument(1,2.0) << "Foo";
-
Ähm, könnten wir die Krypto-Dinge mal Lowlevel nennen und immer Bufferweise krypten lassen? Falls ja, wäre das glaub ich recht geil, weil man keinen einzigen op>> antatschen müßte.
Genauso würde ich mir das vorstellen. Sollte eigentlich auch funktionieren.
Dummerweise kenne ich mich in der Kryptobrange etwa so gut aus, wie ein Hängebauchschwein im Supermarkt.
-
Juhu, es geht voran!
für a) hat sich gerade HumeSikkins bereiterklärt, sich von mir überzeugen zu lassen, daß er da vielleicht maßgeblich beteiligt sein könnte.
Nu aber schnell einen für b) finden.
Bitte melde Dich!
-
Volkard. Welcher Algorithmus denn nu? Reicht (erstmal) bitweise Vignere?
(Diese Frage ist rein informativ gemeint und sollte nicht als Bereiterklärung zum Erfüllen der Aufgabe von Person b aufgefasst werden)
-
Ich bin grad zu beschäftigt um was zu implementieren aber für die Kryptographen unter euch hier meine Linksammlung zum Thema Kryptorgraphie (:
Informationen über Verschlüsselungstechniken
Artikelserie im Linux-Magazin zum Thema Kryptographie mit diversen Tutorials zu unterschiedlichen, verbreiteten Algorithmen.
Grundlagen: http://www.linux-magazin.de/ausgabe/1997/07/Krypto/krypto1.html
Steganographie: http://www.linux-magazin.de/ausgabe/1997/08/Krypto/krypto2.html
DES: http://www.linux-magazin.de/ausgabe/1997/09/Krypto/krypto3.html
IDEA: http://www.linux-magazin.de/ausgabe/1997/10/Krypto/krypto4.html
RC4: http://www.linux-magazin.de/ausgabe/1997/11/Krypto/krypto5.html
Überblick über einige Verschlüsselungsmethoden: http://www.uni-koeln.de/RRZK/aktuell/veranstaltungen/praxis99/MobComPPFolien/sld031.htm
Erklärung der gängigsten Verschlüsselungsmethoden: http://www.infosys.tuwien.ac.at/Teaching/Courses/AK2/vor99/t9/node2.html
Eine Facharbeit über Kryptographie von Michael Wiehl: http://little-nemo.purespace.de/schule/fach/fach_ori.htm
Liste verschiedener Verschlüsselungsalgorithmen http://www.nsc.at/Produkte/Systemsicherheit/algorithmen.htm
Weak keys des RC4 http://marcel.wanda.ch/Archive/WeakKeys.txt-junix
-
Original erstellt von Doktor Prokt:
Volkard. Welcher Algorithmus denn nu? Reicht (erstmal) bitweise Vignere?Ja, danke, Doktor Prokt. Reicht auf jeden Fall. Der allesimpelste tut's erstmal. Ich dachte nichtmal an sowas kompliziertes, dennen Namen ich gar nicht aussprechen kann. Aber wenn's für Dich einfach ist... images/smiles/icon_wink.gif
-
Hallo,
was haltet ihr davon, den Krypto-Part zu einer Policy des Streams zu machen (also zu einem Templateparameter)? Natürlich könnte man auch eine abstrakte Basisklasse verwenden, Templates scheinen mir im Stream-Bereich aber natürlicher.
Etwa so:CryptoStream<FetterCryptoAlgo> MyCryptoStream; CryptoStream YourCryptoStream; // Defautl ist z.B. bitweise Vignere CryptoStream<Yaca> AnotherCryptoStream;@volkard
Ich glaube du hast meinen Satz falsch verstanden. Ich hatte mich eigentlich nicht gemeldet images/smiles/icon_rolleyes.gif
-
@junix danke für die links, ich schaue mir das mal an
-
Keine Ursache. Achja, was ich vergessen hatte: die Im Linux-Magazin erwähnten möglichen Probleme bezüglich RC4 bestehen nicht, solange die Verschlüsselung nicht als RC4 deklariert wird. RSA-Security hat die Markenrechte an RC4 nicht aber die Rechte am Algo.
-junix
-
Oh, mir ist gerade was ganz blödes aufgefallen: bitweise Vignere ist XOR. Dann müsste man eben daraus eine Blockchiffrierung machen, indem man immer n Bits auf einmal verschlüsselt. Das kann ich ja morgen mal machen und dann kann man sich ja später um kompliziertere Algorithmen, z.B. die von junix vorgeschlagenen kümmern. Achso, wie ist das mit der Schlüssellänge? Gibt es für alle Compiler eine Möglichkeit, 64bit große ints darzustellen oder soll das Limit 32 bit betragen ?
