Daten verschlüsseln mit Java oder Datenbank

[vandread]

Hallo Leute,

ich möchte gerne eine Anwendung schreiben die mit einer Datenbank (postgresql) kommuniziert.
Das ist ansich kein Problem und funktioniert auch schon. Jetzt würde ich aber gerne auch Daten die ich in der Datenbank ablege verschlüsseln.

Habe mich im Internet etwas schlau gemacht und erfahren dass man für die Verschlüsselung von Passwörtern (also Passwörter für z.B. Logindaten) mit PBKDF2 verschlüsseln sollte. Java bietet da schon eine implementierung...

Hier mal eine Seite mit einer Vorlage (weiter unten steht PBKDF2WithHmacSHA1):
How to generate secure password hash : MD5, SHA, PBKDF2, BCrypt examples | How To Do In Java

Ich kann den Code leider nicht ganz nachvollziehen aber ich weiß wie man ihn zumindest nutzt...
Soweit ich das aber verstehe kann man mit dieser Methode nur etwas verschlüsseln aber nicht mehr entschlüsseln... Das ergibt bei einem Passwort Sinn. Wie gehe ich aber vor wenn ich z.B. eine Telefonnummer verschlüsseln will? Diese will ich verschlüsseln in der DB ablegen aber später auch wieder entschlüsseln können um sie anzeigen zu können...

Kann mir da jemand weiterhelfen? Oder kenn jemand einen guten Artikel wo das beschrieben wird?

Vielen Dank!

 

[Gucky]

Guck dir mal die Klasse [JAPI]Cipher[/JAPI] an. Vielleicht ist die was für dich.

 

[vandread]

Vielen Dank für den Hinweis...
Habe darauf hin folgendes von Galileo Computing finden können:
Galileo Computing :: Java 7 - Mehr als eine Insel - 22 Sicherheitskonzepte

So wie ich das verstanden habe brauche ich für mein Anliegen einen symmetrischen Schlüssel mit dem ich dann entschlüssel und verschlüssel.
Habe das Ganze mal in einem kleinen Beispiel ausprobiert und es scheint wohl gar nicht so schwer zu sein...

import java.security.InvalidKeyException;
import java.security.NoSuchAlgorithmException;
import javax.crypto.BadPaddingException;
import javax.crypto.Cipher;
import javax.crypto.IllegalBlockSizeException;
import javax.crypto.KeyGenerator;
import javax.crypto.NoSuchPaddingException;
import javax.crypto.SecretKey;

public class Main {

    public static void main(String[] args) throws NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException, IllegalBlockSizeException, BadPaddingException {
        // Beispiel fuer ein zu verschluesselndes Element in der DB
        String s = "Das ist ein Geheim!";
        
        // Keygenerator der einen symmetrischen Schluessel erstellt
        KeyGenerator kg = KeyGenerator.getInstance("DES");
        // Initialisierung des Schluessels (max 56Bit bei DES)
        kg.init(56);
        // Erzeugung des symmetrischen Schluessels
        SecretKey secKey = kg.generateKey();
 
        
        Cipher cipher = Cipher.getInstance("DES");
        
        // Verschluesselung mit dem Schluessel
        cipher.init(Cipher.ENCRYPT_MODE, secKey);
        byte[] sENC = cipher.doFinal(s.getBytes());
        
        System.out.println(new String(sENC));
        
        // Entschluesselung mit dem Schluessel
        cipher.init(Cipher.DECRYPT_MODE, secKey);
        byte[] sDEC = cipher.doFinal(sENC);
        
        System.out.println(new String(sDEC));
    }
}

Eventuell bin ich auch nur zu naiv zu glauben dass das schon eine richtige Verschlüsselung ist...

Was ich aber nicht verstehen will ist folgendes:

Galileo Computing schreib das DES veraltet und unsicher ist, nennen aber keine Alternative die man nutzen sollte und spannen ihre Beispiel mit DES auf...

Wie soll das mit dem Schlüssel funktionieren? Wenn ich heute zB. einen String verschlüssel den in eine txt-Datei schreibe und morgen dann wieder entschlüssel, dann funktioniert das ja gar nicht mehr... Ich muss doch den Schlüssel haben mit dem ich das Ganze verschlüsselt habe... Das würde bedeuten ich bräuchte einen Zentralen Schlüssel in meiner Anwendung der irgendwoe im Code mal erzeugt worden ist oder als Datei bei der Anwendung beiliegt... Aber das ist doch unsicher und naja... Wie macht man sowas "richtig"?

Mir ist auch nicht ganz klar warum diese Initialisierung so wichtig sein soll...

Eventuell hat ja jemand mehr Erfahrung und kann mich aufklären?

 

[Tobse]

Zu deinem ersten Post: Ein Hash-Algorithmus (SHA, MD5 etc...) sind Einwegfunktionen. Siehe Hashfunktion ? Wikipedia.
Hasshfunktionen sind keine Verschlüsselung!

Zur symmetrischen Verschlüsselung:
Als erstes: Ja, DES ist veraltet und unsicher. Aktuelle Alternativen dazu sind:

• AES
• Blowfish / Twofish

Was das Thema mit dem Schlüssel angeht: Völlig korrekt, den Schlüssel musst du einmal erstellen und dann immer den selben verwenden weil du sonst die Daten nichtmehr entschlüsseln kannst. Den einzigen Vorteil den du durch verschlüsselte Daten in der Datenbank erzielen kannst ist dieser: Kann ein Angreiffer in deine Datenbank einbrechen kann er keine Informationen stehlen.
Kann ein Angreiffer aber zusätzlich Zugriff auf das Dateisystem deines Servers bekommen ist es ihm auf jeden Fall möglich, an den Schlüssel zu gelangen und damit ist die Verschlüsselung in der Datenbank hinfällig.

Es macht generell keinen Sinn, eine gesammte Datenbank zu verschlüsseln. Das macht, wenn überhaupt, nur bei den datensätzen zu Kreditkarteniformationen sinn. Passwörter sollten nie Verschlüsselt gespeichert werden sondern nur gehasht (siehe oben).

 

[vandread]

Vielen vielen Dank für deine Infos!
Das macht die Sache sehr viel klarer...

Ich habe den Code mal auf eine AES (128 Bit) verschlüsselung abgeändert.
Leider haben die 192 Bit und 256 Bit Varianten nicht funktioniert...
Advanced Encryption Standard ? Wikipedia

Außerdem schreibe ich den Schluessel in eine Datei raus...
Hoffe dieses Vorgehen ist soweit OK.

import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.security.InvalidKeyException;
import java.security.NoSuchAlgorithmException;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.crypto.BadPaddingException;
import javax.crypto.Cipher;
import javax.crypto.IllegalBlockSizeException;
import javax.crypto.KeyGenerator;
import javax.crypto.NoSuchPaddingException;
import javax.crypto.SecretKey;

public class Main {

    public static void main(String[] args) throws NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException, IllegalBlockSizeException, BadPaddingException {
        // Beispiel fuer ein zu verschluesselndes Element in der DB
        String s = "Das ist ein Geheim!";

        // Keygenerator der einen symmetrischen Schluessel erstellt
        KeyGenerator kg = KeyGenerator.getInstance("AES");
        // Initialisierung des Schluessels
        kg.init(128);
        // Erzeugung des symmetrischen Schluessels
        SecretKey secKey = kg.generateKey();
        
        // Schluessel fuer Wiederverwendung absichern
        try {
            saveKey(secKey);
        } catch (FileNotFoundException ex) {
            Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
        } catch (IOException ex) {
            Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
        }
        
        Cipher cipher = Cipher.getInstance("AES");

        // Verschluesselung mit dem Schluessel
        cipher.init(Cipher.ENCRYPT_MODE, secKey);
        byte[] sENC = cipher.doFinal(s.getBytes());

        System.out.println(new String(sENC));

        // Entschluesselung mit dem Schluessel
        cipher.init(Cipher.DECRYPT_MODE, secKey);
        byte[] sDEC = cipher.doFinal(sENC);

        System.out.println(new String(sDEC));
    }

    public static void saveKey(SecretKey key) throws FileNotFoundException, IOException {
        FileOutputStream fos = new FileOutputStream(new File("key"));

        fos.write(key.getEncoded());

        fos.flush();
        fos.close();
    }
}

Eine kleine Frage habe ich allerdings noch!
Wo genau sollte man diesen Key ablegen?
Sollte dieser so wie du das angesprochen hast auf einem Server liegen, wo ihn dann die Clients runterladen müssen?
Oder ist es auch "OK" wenn der Schlüssel einfach mit der Anwendung kommt, sprich immer beim Client abliegt...?

 

[Tobse]

Ich habe den Code mal auf eine AES (128 Bit) verschlüsselung abgeändert.
Leider haben die 192 Bit und 256 Bit Varianten nicht funktioniert...
Advanced Encryption Standard ? Wikipedia

AES-192 und AES-256 werden von Java nicht von Haus aus unterstützt.

Eine kleine Frage habe ich allerdings noch!
Wo genau sollte man diesen Key ablegen?
Sollte dieser so wie du das angesprochen hast auf einem Server liegen, wo ihn dann die Clients runterladen müssen?
Oder ist es auch "OK" wenn der Schlüssel einfach mit der Anwendung kommt, sprich immer beim Client abliegt...?

Ähm, das ist jetzt was völlig anderes. Wenn die Daten nur vom Server benutzt werden kommt die Schlüsseldatei in ein Verzeichnis das NUR vom Server-Prozess gelesen werden kann, von sonst niemandem.

Wenn es darum geht, dass die Daten mit Clients ausgetauscht werden sollen ist das der völlig falsche Ansatz. Dann musst du für jede Bedingnung über ein Schlüsselaustauschprotokoll (etwa Diffie-Hellman: Diffie-Hellman-Schlüsselaustausch ? Wikipedia) einen sogenannten Session-Schlüssel aushandeln und die Daten dann über eine Verschlüsselte Verbindung schicken. Siehe auch: Transport Layer Security ? Wikipedia

 

[vandread]

Okay jetzt bin ich extrem verwirrt...
Ich glaub das Beste ist wenn ich mal beschreibe was ich eigentlich genau vor habe

Ich habe einen Server auf dem eine Datenbank läuft, um genau zu sein läuft da PostgreSQL.
Auf der Datenbank landen mehr oder weniger sensible Daten...
Das sensibelste sind wohl Bankdaten und eben auch Logindaten bzw. Passwörter...

Als Gegenstück kommt ein Java-Frontend mit dem man Zugriff auf die Daten hat. Das heißt quasi auslesen von Tabellen und eben beschreiben von neuen Datensätzen.
Das Frontend wird parallel genutzt dh. es gibt mehrere User die mit dem Frontend auf die DB zugreifen (auch parallel).

Jetzt ist die Frage wie legt man die Daten sicher ab und wie verwaltet man das am sichersten und schlausten.

Wie ich das aus der Diskussion rausgelesen habe werden Passwörter über eine Hash-Funktion verschlüsselt...
Ich vermute das Schlauste ist bei Anlegen eines neuen Kontos das Passwort via Java (also auf der Client-Seite) mit einer Hash-Funktion umzuwandeln und auf der DB abzulegen... Beim Login wird das eingegebene PW ebenfalls zu einem Hash gewandelt und mit dem Hash auf der DB verglichen...

Wie werden nun z.B. normale Daten behandelt? Sagen wir z.B. eine Kontonummer. Meine Idee war jetzt dass ich einen Key in meiner Anwendung habe mit dem ich z.B. die Kontonummer verschlüssel und entschlüssel... Die Datenbank sieht also nur Verschlüsselte Daten und die Verschlüsselung und Entschlüsselung findet auf der Client-Seite statt... Du sagst jetzt dass ist nicht gut?

Wie genau würde man den eigentlich bei diesem Anwendungsfall vorgehen? Ich will jetzt keinen Code oder so...
Will nur wissen wie man da korrekt vorgehen würde...

 

[Tobse]

Okay jetzt bin ich extrem verwirrt...
Ich glaub das Beste ist wenn ich mal beschreibe was ich eigentlich genau vor habe

Ich habe einen Server auf dem eine Datenbank läuft, um genau zu sein läuft da PostgreSQL.
Auf der Datenbank landen mehr oder weniger sensible Daten...
Das sensibelste sind wohl Bankdaten und eben auch Logindaten bzw. Passwörter...

Als Gegenstück kommt ein Java-Frontend mit dem man Zugriff auf die Daten hat. Das heißt quasi auslesen von Tabellen und eben beschreiben von neuen Datensätzen.
Das Frontend wird parallel genutzt dh. es gibt mehrere User die mit dem Frontend auf die DB zugreifen (auch parallel).

Jetzt ist die Frage wie legt man die Daten sicher ab und wie verwaltet man das am sichersten und schlausten.

Wie ich das aus der Diskussion rausgelesen habe werden Passwörter über eine Hash-Funktion verschlüsselt...
Ich vermute das Schlauste ist bei Anlegen eines neuen Kontos das Passwort via Java (also auf der Client-Seite) mit einer Hash-Funktion umzuwandeln und auf der DB abzulegen... Beim Login wird das eingegebene PW ebenfalls zu einem Hash gewandelt und mit dem Hash auf der DB verglichen...

Wie werden nun z.B. normale Daten behandelt? Sagen wir z.B. eine Kontonummer. Meine Idee war jetzt dass ich einen Key in meiner Anwendung habe mit dem ich z.B. die Kontonummer verschlüssel und entschlüssel... Die Datenbank sieht also nur Verschlüsselte Daten und die Verschlüsselung und Entschlüsselung findet auf der Client-Seite statt... Du sagst jetzt dass ist nicht gut?

Wie genau würde man den eigentlich bei diesem Anwendungsfall vorgehen? Ich will jetzt keinen Code oder so...
Will nur wissen wie man da korrekt vorgehen würde...

Also zunächst: Wenn nur ein Client auf einen Satz Bankdaten zugreifft ist es natürlich sicherer, wenn der client sie selber verschlüsselt.
Zum zweiten: Passwörter werden nicht verschlüsselt sondern gehasht. Hier ist es am besten wenn der Client beim registrieren und anmelden nur das gehashte passwort an den Server schickt.

So, jetzt ist es ja so, dass verschiedene Clients auf die gleichen Daten zugreiffen können. Die Daten zwischen Datenbank und Server zu verschlüsseln macht keinen Sinn. Aber: Auf dem weg vom Server zum clienten müssen die Daten verschlüsselt sein weil sonst jeder mit z.B. Wireshark die Daten auslesen kann.
Wenn ein Client sich mit dem Server verbindet handelst du einen Session-Key per Diffie-Hellman aus. Der verschlüsselt dann sämtliche kommunikation zwischen Client und Server mit AES; dieses Vorgehen ist ein Fall von TSL/SSL.

 

[vandread]

Erneut vielen Dank für deine Aufklärungen.

Jedoch bin ich noch etwas verwirrt, bitte koregiere mich wenn ich dich falsch verstanden haben sollte.
Dass Passwörter nicht verschlüsselt werden, sondern gehasht ist mir nun klar.
So wie ich das aber nun verstehe, schreibst du dass man z.B. eine neue Kontonummer auf jeden Fall auf der Client-Seite verschlüsselt und dann an die DB schickt. Wenn man eine Kontonummer lesen will, holt man sich die verschlüsselte Kontonummer von der DB und entschlüsselt diese auf der Client-Seite. Das ganze wird natürlich mit einem Schlüssel gemacht. Damit das funktioniert, muss dieser Schlüssel immer und zwar bis zur Vernichtung der DB und des Systems der selbe sein! Wenn das soweit korrekt ist was ich sage. Wo und wie verwaltet man diesen Schlüssel? Als einfach Datei die im Verzeichnis der Anwendung aka Client?

Wenn oben alles korrekt ist, dann verstehe ich nicht warum eine verschlüsselte Verbindung zur Datenbank noch unbedingt notwendig ist. Schließlich schicke in dann zur Datenbank einen Hash bzw. verschlüsselte Werte. Würde also heißen, wenn jemand mit Wireshark mit schneidet, sieht er den verschlüsselten Wert kann aber damit nichts anfangen weil er den key nicht kennt. Er müsste sich also erst den key besorgen. Natürlich könnte das jemand tun wenn er es wirklich darauf anlegen würde...

Du meinst aber man sollte die verschlüsselten Werte noch einmal verschlüsseln in dem man die Kommunikation verschlüsselt. Würde also heißen wenn Mr. X mit Wireshark in der Leitung sitzt, sieht er nicht viel und selbst mit dem key, mit dem die Werte auf der Clien-Seite verschlüsselt worden sind kann er nicht viel anfangen...

In diesem Fall müsste ich jemanden fürchten der sich Zugang zur DB verschafft und den key besitzt mit dem auf der Client-Seite verschlüsselt worden ist.

Sorry dass ich das nicht so schnell begreife ):

 

[Tobse]

So wie ich das aber nun vertehe, schreibst du dass man z.B. eine neue Kontonummer auf jeden Fall auf der Client-Seite verschlüsselt und dann an die DB schickt. Wenn man eine Kontonummer lesen will, holt man sich die verschlüsselte Kontonummer von der DB und entschlüsselt diese auf der Client-Seite. Das ganze wird natürlich mit einem Schlüssel gemacht. Damit das funktioniert, muss dieser Schlüssel immer und zwar bis zur Vernichtung der DB und des Systems der selbe sein! Wenn das soweit korrekt ist was ich sage. Wo und wie verwaltet man diesen Schlüssel? Als einfach Datei die im Verzeichnis der Anwendung aka Client?

Dann hab ich mich unverständlich ausgedrückt. Es ist zwischen zwei Fällen zu unterscheiden:
1. Die sensiblen Daten gehören einem Client und werden nur auf dem Server gespeichert.
2. Die sensiblen Daten gehören dem Dienst (also dem Betreiber) und werden deshalb auf dem Server gespeichert weil mehrere Clients darauf zu greiffen

Im ersten Fall:
Jeder Client erstellt seinen eigenen Schlüssel und sendet die Daten verschlüsselt an den Server, der speichert die Daten so direkt in der Datenbank und liefert sie auch so wieder aus. Schließlich kann auch nur der Client sie wieder entschlüsseln.

Im zweiten Fall:
Die Verbindung zwischen Client und Server ist verschlüsselt, sprich sowohl beim Client wie auch beim Server liegen die Daten im Klartext vor.

 

[vandread]

Also mein Fall ist folgender:

Der besitzer der Daten ist der Betreiber selber. Sprich der Betreiber hat alle Daten und will diese auf einer Datenbank ablegen. Um dies zu tun, gibt es ein Java-Frontend mit dem z.B. die Verwalter der Daten (können mehrere Personen sein) neue Daten aufspielen können oder alte bearbeiten etc.

Ich würde jetzt sagen dass es dann nach deinem Beispiel zum zweiten Fall gehören würde.
Jedoch ist mir nicht klar warum man die Daten auf der Datenbank im Klartext abspeichern sollte. Ist dies nicht unsicher? Was wenn man jemand direkten Zugang zur Datenbank erhält?

Wäre es denn nicht schlau die Daten (nur sensible wie z.B. Kontonummer) mit einem Key zu verschlüsseln und dann alles auch verschlüsselt über ssl an die Datenbank zu senden?

Dann würden die sensiblen Daten verschlüsselt auf der Datenbank abliegen und falls jemand wirklich mal auf die Datenbank kommt, bringt ihm dies nichts, da er auch zugriff zu der Anwendung braucht um an den Key zu kommen...

Oder denke ich da schon wieder irgendwie in die falsche Richtung? ):

 

[Joose]

Jedoch ist mir nicht klar warum man die Daten auf der Datenbank im Klartext abspeichern sollte. Ist dies nicht unsicher? Was wenn man jemand direkten Zugang zur Datenbank erhält?

Wäre es denn nicht schlau die Daten (nur sensible wie z.B. Kontonummer) mit einem Key zu verschlüsseln und dann alles auch verschlüsselt über ssl an die Datenbank zu senden?

Dann würden die sensiblen Daten verschlüsselt auf der Datenbank abliegen und falls jemand wirklich mal auf die Datenbank kommt, bringt ihm dies nichts, da er auch zugriff zu der Anwendung braucht um an den Key zu kommen...

Ja es ging ihm aber darum, gehören die Daten nur dem Kunden, sollte auch nur der Kunde diese Daten lesen können. ==> sprich der Kunde verschlüsselt sie und sie werden so abgespeichert.

Gehören die Daten dir/dem Betreiber so darf dieser die Daten auch lesen. ==> sprich der Betreiber sollte sie so verschlüsseln das nur er sie benutzen kann.
Aber zwischen Client und Server werden die Daten im Klartext ausgetauscht, hier ist dafür die Verbindung verschlüsselt.

 

[Tobse]

Jedoch ist mir nicht klar warum man die Daten auf der Datenbank im Klartext abspeichern sollte. Ist dies nicht unsicher? Was wenn man jemand direkten Zugang zur Datenbank erhält?

Wenn dein Server richtig eingerichtet ist dann ist es nurnoch ein minimaler Mehraufwand sich Zugang zum gesamten Server zu verschaffen wenn man schon auf die Datenbank Zugreiffen kann. Im besten Fall hält dann die Verschlüsselung in der Datenbank den Angreiffer 1-2 Stunden auf, mehr aber auch nicht.

Wäre es denn nicht schlau die Daten (nur sensible wie z.B. Kontonummer) mit einem Key zu verschlüsseln und dann alles auch verschlüsselt über ssl an die Datenbank zu senden?

Wenn der Datenbank-Server nicht auf dem gleichem Computer läuft wie deine Server-Software MUSS SSL zwischen Server und Datenbank auf jeden Fall sein, das ist völlig richtig. In diesem Fall würde eine zusätzliche Verschlüsselung in der Datenbank schon Sinn machen.
Wenn aber beide auf der gleichen Maschine laufen (s.o.) kannst du den Datenbankzugriff auf 127.0.0.1 beschränken und dann kommt von aussen garkeiner mehr in die Datenbank.

 

[vandread]

Okay also das Ganze scheint wohl doch noch etwas verstrickter zu sein als ich vermutet habe

Also ich versuch das noch mal etwas genauer abzubildung...

• Die Software und der Server "gehören" einem Verein.
• Der Verein verwaltet seine Mitglieder mittels der Software.
• Die Daten mit der die Software arbeitet, sollen auf einer DB abgelegt werden.
• Die Software wird von verschiedenen Vereinsmitglieder benutzt (Vorstand, Sekretär).
• Die Datenbank läuft auf einem extra Rechner der sich im Netzwerk befindet ODER wird bei einem Dienstleiter angemietet.

Also kleines Fallbeispiel:
Du kommst zum Verein und teilst dem Sekretär deine Anschrift und Bankverbindung mit.
Dieser gibt deine Daten in die Software ein, welche wiederum die Daten in der DB ablegt.

Also...

Für diesen Fall hätte ich jetzt gesagt muss/sollte folgendes gemacht werden:

• Verbindung zur Datenbank muss verschlüsselt sein! Also eine SSL-Verbindung. (Dabei ist es egal ob die DB im eigenen Netzwerk ist oder irgendwo im Web)
• Sensible Daten wie Kontonummern sollten ebenfalls verschlüsselt werden. Die Software verschlüsselt (mit einem KEY der simpel bei der Software hinterlegt ist) die Daten z.B. mit AES-128Bit und schickt diese dann verschlüsselt zur DB. (Dieser Schritt ist meiner Meinung nach nur notwendig wenn die DB sich im Web befindet, oder sollte man einfach komplett misstrauisch sein und trozdem verschlüsseln?)

Tut mir leid dass mir das nicht so leicht in den Kopf will ):
Eventuell habe ich mir selber ins Knie geschossen als ich mit Client und Server angefangen haben und wir hatten unterschiedliche Ansichten/Vorstellungen was damit gemeint war...

 

[Tobse]

Also, um das abschließend klarzustellen:

Du benutzt 2 Verschlüsselungen:

1. zwischen Client-Software und Server-Software
2. zwischen Server-Software und Datenbank

Der Schlüssel für (1) wird für jede Verbindung neu mit Diffie-Hellman ausgeahndelt.
Der Schlüssel für (2) wird einmalig erstellt und auf dem Computer mit der Server-Software gespeichert. Sofern möglich legst du für die Server-Software einen eigenen UNIX-User an und die Datei mit dem Schlüssel wird der Gruppe

nogroup

und dem Benutzer der Serversoftware zugewiesen; sie bekommt folgende zugriffsrechte:

--r

.

Für (1) empfehle ich AES-128 im CTR Modus.
Für (2) empfehle ich AES-192 oder AES-256 im CBC oder OFB Modus.

ACHTUNG: wenn CTR, CBC und OFB sowie "Padding" oder "PKCS5" dir unbekannte Begriffe sind sind diese beiden Wikipedia-Artikel Pflichtlektüre:
Padding (Informatik) ? Wikipedia
Block cipher mode of operation - Wikipedia, the free encyclopedia

Java unterstützt ja leider nur AES-128. Wenn du AES-192 oder AES-256 benutzen willst bemühe Google oder kontaktiere mich per PM.

[EDIT]Für (1) ist es ebenfalls EIN ABSOLUTES MUSS, die Identität des Servers zu prüfen. Das geschieht mithilfe eines Asymmetrischen Kryptographieverfahrens, etwa RSA oder ElGamal. Wird das ausgelassen oder nicht richtig mit dem Diffie-Hellman Schlüsselaustausch kombiniert kann ein angreiffer über eine Man-In-The-Middle Attacke alle Daten abgreiffen welche über die (verschlüsselte) Verbindung gehen.[/EDIT]

 

[turtle]

Die Datenbank läuft auf einem extra Rechner der sich im Netzwerk befindet ODER wird bei einem Dienstleiter angemietet.

Das Mieten eines Dienstleisters für eine anscheinend sehr sensible DB finde ich nicht passend. Dieses hat das Risiko, das du dem Dienstleister "blind" vertrauen musst, was Aktualität/Stabilität der Systeme angeht.

Ist das die Mitglieder-DB der NSA, oder was?

Eine DB würde ich nie ins Netz stellen. Stattdessen würde ich sie so einrichten, das nur intern zugegriffen werden kann. Niemand muss mit einem SQL-Tool von außen in die DB schauen. Und wenn doch, würde ich dafür einen VPN-Tunnel aufbauen.

Daher finde ich die doppelte Verschlüsselung, insbesondere von Server<->DB nicht notwendig, weil niemand diesen Traffic belauschen kann.