nicht angemeldet
hi molily,
Dank für die Link-Liste.
Wo ist denn da die Unsicherheit?
Grundlagen:
http://tonyarcieri.com/whats-wrong-with-webcrypto
s. erste Antwort.
"What systems programming functionality does Javascript lack? Here's a starting point: a secure random number generator."
Und:
"SJCL is also practically the only example of a trustworthy crypto library written in Javascript, and it's extremely young.
The authors of SJCL themselves say, "Unfortunately, this is not as great as in desktop applications because it is not feasible to completely protect against code injection, malicious servers and side-channel attacks." That last example is a killer: what they're really saying is, "we don't know enough about Javascript runtimes to know whether we can securely host cryptography on them". Again, that's painful-but-tolerable in a server-side application, where you can always call out to native code as a workaround. It's death to a browser."
Crockford zeigt anschaulich das Problem, wenn ein Key nicht wirklich zufällig ist. Er verweist hier auch auf: Marc Stiegler.
Den Stiegler-Vortrag finde ich grundsätzlich interessant, weil es hier um einen Programmierstil geht, der meinem Verständnis Zuständigkeiten und Sicherheit verknüpft.
Was ich nicht ganz kapiert habe, das geht aber weg von der eigentlich Kryptografie, ist um 37:30 herum (bzw. dann die Nachfrage bei 38:45) seine Autentifizierungsmethode wo man selbst signierte Zertifikate nutzen kann, wobei im (Sub-)Domain-Namen der „fingerprint of the public-and-private-key-pair, that is being held by the Service/Website" untergebracht ist. Waterken-Sever spielt dabei eine oder die zentrale Rolle. Das habe ich auf die Schnelle nicht verstanden (auch nicht nach einem Besuch von waterken.com bzw. der sourcefourge-seite).
Generell die Diskussion um Crypto.cat:
Ist jetzt ein, oder "das" Beispiel für (angeblich) sichere/kryptografierte Kommunikation als Web-App?
http://www.wired.com/2012/08/wired_opinion_patrick_ball/all/
"My concerns stem from a sharp debate over software called CryptoCat – a debate spurred largely by an admiring profile at Wired. CryptoCat is a web-based chat application which uses encryption to scramble the contents of a conversation, in theory resisting electronic snooping. The interesting twist is that CryptoCat does the crypto without using the easily-thwarted security built into browsers (called SSL), and without requiring the user to download and install additional software (like Pidgin and OffTheRecord).
Seems great, right?
Well, not so great. CryptoCat is one of a whole class of applications that rely on what’s called “host-based security”. The most famous tool in this group is Hushmail, an encrypted e-mail service that takes the same approach.
Any host-based system that delivers the encryption engine to you each time you log in, and in which your keys reside on the server, you are never secure against the host (there’s new research on this called “host-proof hosting,” but it’s a long way from being ready to use in real applications). That means that if the host attacks you, or they fail to protect themselves, your encrypted data will be available to them.”
Heißt vereinfacht: SSL ist "shit" und host-based-encryption auch? Marc Stiegler aber nutzt https um mit seinem Server zu kommunizieren in dem Beispiel und im oben verlinkten matasano-Artikel heißt es: "But I can get random numbers over the Internet and use them for my crypto! How can you do that without SSL? And if you have SSL, why do you need Javascript crypto? Just use the SSL." Ist SSL nun "gut" oder "schlecht"? Es steht dort ja auch: "The problem is, having established a secure channel with SSL, you no longer need Javascript cryptography". ??? Vielleicht steht ich da auch grade auf dem Schlauch.
https://blog.crypto.cat/2012/08/moving-to-a-browser-app-model/
"As a project, Cryptocat’s mission is to find the very best, most functional balance between security and accessibility. In this scenario, after considering the advice of the security community, we have decided that the security benefits of moving towards a local browser plugin only model outweigh the accessibility concerns."
Klare Aussage: Plugin funktioniert!
Generell die Diskussion um Mega.co.nz:
https://www.schneier.com/blog/archives/2013/01/the_security_of_6.html
Wie du jetzt auf Mega.co.nz kommst, kapiere ich nicht ganz. Ich finde:
a) auf der Seite als Kommentar: "i don't think so they care about security of files , its just to by pass laws as people just upload movie files on it like megaupload ..." - klingt logisch, wenn ich nicht weiß, was da drinne ist, kann ich auch nicht haftbar gemacht werden, "echte" encryption ist also zweitrangig
b) der erste von den "this"-links auf schneiers seite: http://arstechnica.com/business/2013/01/megabad-a-quick-look-at-the-state-of-megas-encryption/ - "The biggest problem with Mega's methods is the lack of entropy gathered in the generation of the RSA key pair. An encryption key needs to be difficult to guess, and so typically when one is generated it is created randomly by an algorithm. Computers, though, are notoriously non-random, and so the "random" numbers generated by their random number generation routines need to be supplemented by a factor called entropy. Entropy is "true" randomness, gathered by the computer from various sources—keypresses and mouse movements, or sound from a microphone, or any number of other things. Some modern CPUs even contain "true random number generators," which use random atomic vibrations in the CPU as entropy sources." bezieht sich wieder auf die schon erwähnte Notwendigkeit von echten Zufallszahlen, die u.a. auch im Crockfordvortrag anschaulich demonstriert werden.
Fazit(?):
1. man braucht echte Zufallszahlen, zB. über ein Plugin, nicht über Javascript
2. der Server muss "dumm" bleiben, darf keine Schlüssel speichern
3. Frage: SSL/TSL - https ist sicher oder nicht?
4. Als Schlussforlgerung aus dem Stiegler-Vortrag: self-signed certificates sind ein praktikabler weg, weil sonst Zertifikate (zu) teuer sind?
mfg
tami
Auge