Tankist November 7, 2009 Wo ist der Unterschied zwischen KeePass 1.16 "Classic" und KeePass 2.09 "Professional". Sollte beides Open Source sein, nur frage ich mich wo der Sinn in einer Produktdifferenzierung liegt bei frei erhältlicher Software? Grüße! Diesen Beitrag teilen Link zum Beitrag
thomas80 November 7, 2009 Wo ist der Unterschied zwischen KeePass 1.16 "Classic" und KeePass 2.09 "Professional". Sollte beides Open Source sein, nur frage ich mich wo der Sinn in einer Produktdifferenzierung liegt bei frei erhältlicher Software? Grüße! Bei manchen Menschen frage ich mich, was die zwischen den Schultern eigentlich tragen...statt dumme Fragen hier zu posten, sollte jene Menschen einfach nur lesen und das Gelesene dann begreifen KeePass currently is available in two different editions: 1.x and 2.x. They are fundamentally different (2.x is not based on 1.x). They mainly differ in portability and functionality: Quelle: Keypass Edition Comparison Diesen Beitrag teilen Link zum Beitrag
xolgo November 8, 2009 · bearbeitet November 8, 2009 von xolgo Den OTC sehe ich nicht unter gängigen Crypto-Algorithmen. Ist eben die Frage, wie man "gängige" Algorithmen definiert. Den 128-Bit AES/Rijndael beispielsweise kann man bekanntlich brechen durch ... nicht in vertretbarer Zeit lösbar. ...Doch wie soll man beweisen, dass es nicht geht? Sorry, aber ich versteh Deine Frage nicht so ganz. Du sagst doch selbst, dass das Problem lösbar ist. Durch zunehmende Rechenleistung wird der Zeitaufwand in der Zukunft natürlich schrumpfen. Daher ist es doch klar ersichtlich, dass man eben gerade nicht beweisen kann, dass der Algorithmus niemals innerhalb kurzer Zeit brechbar sein wird. Diesen Beitrag teilen Link zum Beitrag
ipl November 8, 2009 Das Problem, das hier angesprochen wurde, hat weniger mit vorhandener Rechenleistung zu tun, sondern dass es generell relativ schwer zu beweisen ist, dass man ein bestimmtes Problem nicht schneller lösen kann, als eine bestimmte untere Schranke (gemessen nicht in Sekunden, sondern in der Anzahl der nötigen Rechenoperationen). Vielleicht gibt es ja unentdeckte Algorithmen, die die Verschlüsselung schneller knacken können, als die aktuellen. Für einige Probleme gibt es solche Beweise, aber bei der NP-Klasse z.B. gibt es diese noch nicht (für die Lösung dieses Problems gibt es übrigens ein paar Millionen an Preisgeldern). Wie das bei konkreten Verschlüsselungsalgorithmen zur Zeit genau aussieht, müsste ich nachschauen, aber ich glaube auch, dass da in der Hinsicht wenig bewiesen werden konnte. Bei manchen Menschen frage ich mich, was die zwischen den Schultern eigentlich tragen... Und ich frage mich manchmal, was bei der Erziehung ganz bestimmter Menschen schief gelaufen ist. Diesen Beitrag teilen Link zum Beitrag
jpjg November 8, 2009 Ist eben die Frage, wie man "gängige" Algorithmen definiert. Ich denke da hauptsächlich an den symetrischen 3DES und seine Nachfolger, die AES-Familie (Rijndael, Twofish, Serpent). Ich gehe davon aus, der eine oder andere davon wird in den hier angesprochene Programmen verwendet. Für einige Probleme gibt es solche Beweise, aber bei der NP-Klasse z.B. gibt es diese noch nicht (für die Lösung dieses Problems gibt es übrigens ein paar Millionen an Preisgeldern). Wie das bei konkreten Verschlüsselungsalgorithmen zur Zeit genau aussieht, müsste ich nachschauen, aber ich glaube auch, dass da in der Hinsicht wenig bewiesen werden konnte. Ich wüsste nicht, dass es da irgendwelche Preisgelder gibt. Es ist aber trotzdem eine lebhaftes Forschungsfeld. Für interessierte, eine gute Übersicht über die Problematik ist zu finden in Bruce Schneier's Crypto-Gram Newsletter. So we're in a quandary. We might have an amazing new cryptanalytic technique, but we don't know if there's an error in the analysis, and there's no way to test the technique empirically. We have to wait until others go over the same work. And to be sure, we have to wait until someone improves the attack to a practical point before we know if the algorithm was broken to begin with. In any case, there's no cause for alarm yet. These attacks can be no more implemented in the field than they can be tested in a lab. No AES (or Serpent) traffic can be decrypted using these techniques. No communications are at risk. No products need to be recalled. There's so much security margin in these ciphers that the attacks are irrelevant. But there is call for worry. If the attack really works, it can only get better. My fear is that we could see optimizations of the XSL attack breaking AES with a 2^80-ish complexity, in which case things starts to get dicey about ten years from now. That's the problem with theoretical cryptanalysis: we learn whether or not an attack works at the same time we learn whether or not we're at risk. The work is fascinating. During the AES process, everyone agreed that Rijndael was the risky choice, Serpent was the conservative choice, and Twofish was in the middle. To have Serpent be the first to fall (albeit marginally), and to have Rijndael fall so far so quickly, is something no one predicted. But it's how cryptography works. The community develops a series of algorithms for which there are no known attacks, and then new attack tools come out of the blue and strike a few of them down. We all scramble, and then the cycle repeats. Diesen Beitrag teilen Link zum Beitrag
xolgo November 8, 2009 Das Problem, das hier angesprochen wurde, hat weniger mit vorhandener Rechenleistung zu tun, sondern dass es generell relativ schwer zu beweisen ist, dass man ein bestimmtes Problem nicht schneller lösen kann, als eine bestimmte untere Schranke (gemessen nicht in Sekunden, sondern in der Anzahl der nötigen Rechenoperationen). Jein. Klar, es ist quasi unmöglich zu beweisen, dass es keine (schnellen) Lösungsalgorithmen gibt. Das muss man eben hinnehmen oder OTP ;-) Rein praktisch aber zählt doch die Frage: In welcher Zeit ist der verwendete Algorithmus aktuell zu brechen. Davon macht man die Entscheidung abhängig, was man verwenden will. Erhöhte Rechenleistung betrifft alle Algorithmen und zukünftige prinzipiell schnellere Methoden kann man wohl nicht vorausahnen und daher in der Entscheidung nicht berücksichtigen. Ich wüsste nicht, dass es da irgendwelche Preisgelder gibt. Ich nehme an, ipl bezog sich hierauf: http://de.wikipedia.org/wiki/Millennium-Probleme Diesen Beitrag teilen Link zum Beitrag
jpjg November 8, 2009 Jein. Klar, es ist quasi unmöglich zu beweisen, dass es keine (schnellen) Lösungsalgorithmen gibt. Das muss man eben hinnehmen oder OTP ;-) Das ist der Punkt. Nochmal zum OTP. Leider ist der OTP etwas unhandlich. Man braucht zu jedem Plaintext einen gleich langen Schlüssel, der nach einmaliger Nutzung sofort verfällt. Im Grunde genommen braucht man also parallel zum zu sichernden Kanal, einen anderen bereits gesicherten Kanal, gleicher Bandbreite. Damit ist der OTC in der Theorie zwar nachweisbar sicher, in der Praxis hängt seine Sicherheit eben davon ab, wie sicher der gesicherte Kanal ist. Nach dem aktuellen stand der Technik ist man also darauf angewiesen, dass die Boten nicht käuflich sind. (Boten tragen ja die CDs mit den Schlüsseln hin und her B) . Rein praktisch aber zählt doch die Frage: In welcher Zeit ist der verwendete Algorithmus aktuell zu brechen. Davon macht man die Entscheidung abhängig, was man verwenden will. Erhöhte Rechenleistung betrifft alle Algorithmen und zukünftige prinzipiell schnellere Methoden kann man wohl nicht vorausahnen und daher in der Entscheidung nicht berücksichtigen. Genau. Wobei die benötigte Rechenleistung eben von der verwendeten Schlüssellänge abhängt. Die Schlüssellängen werden so dimensioniert, dass davon ausgegangen werden kann, dass bei derzeit möglicher Rechenleistung niemand an die chifrierte Information drankommt. Und zwar nicht solange sie von irgendeinem Nutzen sein könnte. Ich weiß es nicht genau, aber wird wohl ein Menschenleben sein. D.h. mit steigender Rechenleistung müssen auch die Schlüssellängen steigen oder neue/verbesserte Algorithmen müssen her (deshalb z.B. aus DES wurde 3DES). Und zwar Vorausschauend. Also ein anderes nicht trivial zu lösendes Problem. Diesen Beitrag teilen Link zum Beitrag
xolgo November 9, 2009 Das ist der Punkt. Nochmal zum OTP. Leider ist der OTP etwas unhandlich. Das OTP-Beispiel zeigt mE sehr deutlich, wo das eigentlich Problem liegt. Wenn ich mir die Kryptographie-Welt so ansehe, in der auch zahlreiche asymmetrische Verfahren im Einsatz sind, die o.g. Einschränkung nicht haben, dann scheitert es doch oft nicht an der Bandbreite o.ä. sondern am Nutzungswillen und Verständnis der User. Warum setzt sich weder PGP/GnuPG noch S/MIME durch? Warum sind >90% der privaten Festplatten generell unverschlüsselt? Warum gibt es so viele Passphrasen, die der Vorname der Freundin oder der Name des Hundes entsprechen? Ob die Bank Dir jetzt eine Liste mit TANs oder eine CD mit Schlüsseldaten schickt, das macht fast keinen Unterschied. Die Bandbreite ist nicht das Problem. Aber es gibt doch genügend User, die Spam öffen, auf die LInks klicken und TANs auf jeder Website eintippen, egal wie schlecht das Deutsch darauf ist. Das Problem ist mE nicht der sichere Kanal bei symmetrischen Verfahren oder die Knackbarkeit (asymmetrischer) Verfahren. Es sind nicht motivierte und schlecht informierte User. Diesen Beitrag teilen Link zum Beitrag
cre November 10, 2009 · bearbeitet November 10, 2009 von cre ....Warum sind >90% der privaten Festplatten generell unverschlüsselt?... Also ich bin ein ziemlich Sicherheitsbewusster Anwender, meine "sensiblen" Daten (Exceldateien mit Kontobuchungen) packe ich in ein 7zip Archiv mit AES 256. Ich habe mir gestern einen neuen PC mit Windows 7 Professional bestellt und werde dort EFS einsetzen (ich nutze auch Linux/BSD). Aber wirklich fatal finde ich es nicht, das >90% aller User ihre Festplatte nicht verschlüsseln. 1. Wie sensibel sind die meisten Daten schon? 2. Jemand muss physisch bei mir Zuhause einbrechen, Festplatte/Computer stehlen, sich ein wenig mit NTFS rumplagen (gut, dass ist kein Hindernis) und hätte dann was? Meine IST-Kontostände in einer Excel-Datei? Wen interessiert das? Keine Frage, du hast natürlich recht...Setzt man Aufwand (z.B. EFS zu aktivieren, TrueCrypt zu installieren) gegen nutzen, sollte es sofort jeder machen. Wichtiger für mich: - alles im Sinne von "damit kann sich jemand unter meinem Namen legitimieren" (TAN / Kennwörter...) speichere ich nie digital (trotzt Verschlüsselungstechniken) - meine TAN liegt in einem physischen Tresor, getrennt von Zugangsdaten Diesen Beitrag teilen Link zum Beitrag
Tankist November 12, 2009 · bearbeitet November 14, 2009 von Tankist Kann man bei KeePass und/oder Password Safe einstellen das das Programm Benutzername und Passwort auf der Seite einfügt sobald man sie ansurft? Quasi automatisch falls die "richtige" URL gewählt wurde. Bis jetzt muss ich immer die Seite öffnen, dann auf KeePass klicken und dann bei den Einträgen mit rechter Maustaste "Auto-Einfügen" auswählen, ich hätte es wie gesagt vollautomatisch, geht das? Mit freundlichen Grüßen! P.S.: So, jetzt gibt es erstmal einen kleinen Zwischenbericht. Ich habe jetzt 2 Truecrypt Kontainer mit der Version 6.3 erstellt. Auf einem habe ich meine ganzen Daten die ich gerne persönlich haben möchte und im anderen Kontainer sind die TAN Listen. Gefährlich aber sehr praktisch. Weiterhin habe ich jetzt "Password Safe" und "KeePass Password Safe" ausprobiert. Ja die Namensgebung ist unpraktisch weil überschnitten und ich muss sagen dass KeePass derbe überladen wirkt mit Funktionen die keiner brauch, z.b. der Datenbank einen Namen geben. Password Safe dagegen gefällt mir sehr, mit einem Rechtsklick kann ich den Befehl geben: die URL anzusteuern, Nutzername, Passwort einzugeben und Eingabe zu drücken. Total genial sowas habe ich gesucht. Trotz allem bin ich kein Experte in beiden Programmen und würde jeden hier bitten die Pros und Kons gegenüber zu stellen. Gruß! Diesen Beitrag teilen Link zum Beitrag
