Hai,
ich habe eine Web-Anwendung deren jdk nicht veraendert werden darf und mit diesem nur 128 bit aes verschl. beherrscht.
Mein Problem ist, dass ich mit dieser Web-Anwendung eine URL erzeugen muss, deren parameter 192bit AES verschl. werden muessen. Dies verlangt wiederum eine anderer (europ.) Hersteller.
Hat jemand eine idee wie ich ein jsp schreiben kann, dass ggf. ein shellscript, ne pipe oder was auch immer nutzt, um etwas heoeherbitig aes zu verschluesseln. Ich muss das dann aus dem jsp heraus steuern koennen.
Gruß,
Lisan.
AES encr. via shell ?
Re: AES encr. via shell ?
uljanow hat Recht, aespipe ist recht einfach zu handhaben; guck mal hier:
http://sunoano.name/ws/public_xhtml/deb ... ar_archive
Den Teil mit dem tarball kannst du natuerlich vergessen aber der aespipe teil ist denke ich recht interessant fuer dich.
http://sunoano.name/ws/public_xhtml/deb ... ar_archive
Den Teil mit dem tarball kannst du natuerlich vergessen aber der aespipe teil ist denke ich recht interessant fuer dich.
Re: AES encr. via shell ?
Hallo,
Was ist denn mit
Man kann z. B. ohne das JDK zu aendern beim java Aufruf eine eigene "security.properties" setzen, die dann einen
Security Provider enthaelt, der die gewuenschte Verschluesselung enthaelt.
Ciao
Stefan
Was ist denn mit
gemeint?jdk nicht veraendert werden darf
Man kann z. B. ohne das JDK zu aendern beim java Aufruf eine eigene "security.properties" setzen, die dann einen
Security Provider enthaelt, der die gewuenschte Verschluesselung enthaelt.
Ciao
Stefan
Bürokratie kann man nur durch ihre Anwendung bekämpfen.
Re: AES encr. via shell ?
Hm - ich bin nicht der javacrack habe aber gelesen, dass aus rechtlichen gruenden mit dem jdk nur 128bitige aes verschl. moeglich ist.
Re: AES encr. via shell ?
Hallo Lisan,
bei Security Algorithmen gibt es Exportbeschraenkungen fuer Security Algorithmen.
Daher unterstuetzen - soweit ich weiss - die JDK's, die man aus den USA herunterladen kann, auch heute noch
Security Provider, deren Algorithmen Umfang eingeschraenkt ist.
Daher gibt es z.B. bei verschiedenen JDK's Ergaenzungen, die man von Servern ausserhalb der USA laden kann,
damit die Exportbestimmungen nicht mehr greifen.
Es ist aber gerade Sinn und Zweck der Java Security Architektur, dass man Provider hinzufuegen kann,
um fehlende Algorithmen zu ergaenzen. Damit wird das JDK nicht geandert.
Ciao
Stefan
bei Security Algorithmen gibt es Exportbeschraenkungen fuer Security Algorithmen.
Daher unterstuetzen - soweit ich weiss - die JDK's, die man aus den USA herunterladen kann, auch heute noch
Security Provider, deren Algorithmen Umfang eingeschraenkt ist.
Daher gibt es z.B. bei verschiedenen JDK's Ergaenzungen, die man von Servern ausserhalb der USA laden kann,
damit die Exportbestimmungen nicht mehr greifen.
Es ist aber gerade Sinn und Zweck der Java Security Architektur, dass man Provider hinzufuegen kann,
um fehlende Algorithmen zu ergaenzen. Damit wird das JDK nicht geandert.
Ciao
Stefan
Bürokratie kann man nur durch ihre Anwendung bekämpfen.
Re: AES encr. via shell ?
Ich finde dazu immer das folgende:
Das sieht aber danach aus der jdk zu erweitern, was ich nicht kann. So wir ich das verstehe muss ich die jars der Unlimited strength edition in das java-home kopieren. Mein JSP laeuft auf einem untouchable tomcat.Strong Versus Unlimited Strength Cryptography
Due to import-control restrictions imposed by some countries, the jurisdiction policy files shipped with the Java 2 SDK, v 1.4 only permit strong cryptography to be used. An unlimited strength version of these files (that is, with no restrictions on cryptographic strength) is available for download (http://java.sun.com/products/jce/index- ... edDownload), however.
After installing the unlimited strength version, to use key sizes of 192 and 256 bits, simply provide the required length of the key. The following line of code illustrates how to set the key size to 256 bits:
kgen.init(256); // 128 and 192 bits also available
The JCE examples given here show how to use AES for different key sizes, but they don't touch upon the more intricate issues -- like key management or key exchange algorithms. In practice, you may be more likely to use a protocol like Secure Socket Layer (SSL), which negotiates session keys using public keys that are subsequently used for bulk encryption.