Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

Legend

Alter Hase

Beiträge: 731

Beruf: Softwareentwickler

  • Private Nachricht senden

21

29.03.2014, 14:21

Btw. @MitgliedXYZ: Mit akademisch meinte ich eher, dass wegen der von mir beschrieben Problematik man den entsprechenden Ansatz nicht mehr einsetzen sollte. Akademisch gelten solche Verfahren schon lange bevor man in der freien Wildbahn die Exploits für die Script Kiddies rumgeistern. Hat aber auch seinen Sinn, denn von den ersten Schwächen, bei denen man es vielleicht schafft aus einer 128 Bit-Cipher effektiv eine 122-Bit Cipher zu machen, ist es nach dem was ich in Kryptographie damals gehört hatte, meistens nur noch eine Frage der Zeit. Ist der Ansatz für eine Lücke da folgt der Rest relativ automatisch.

Das soll nicht heißen, dass MD5 jetzt okay wäre. MD5 kannste noch dazu benutzen, um die Datenintegrität von Downloads zu verifizieren, aber für kryptographische Aufgaben sollte man schon lange nichts mehr neues mit diesem Algorithmus entwickeln. Dein Programm wird ja vielleicht ein paar Jahre im Einsatz sein. Und dann ist ein Hashalgorithmus der heute schon kleine Schwächen aufweißt (wie wohl z.B. die SHA-Familie ...) absoluter Ramsch.
"Wir müssen uns auf unsere Kernkompetenzen konzentrieren!" - "Juhu, wir machen eine Farm auf!"

Netzwerkbibliothek von mir, C#, LGPL: https://sourceforge.net/projects/statetransmitt/

MitgliedXYZ

Alter Hase

  • »MitgliedXYZ« ist der Autor dieses Themas

Beiträge: 1 369

Wohnort: Bayern

  • Private Nachricht senden

22

29.03.2014, 14:35

@Legend
Ok, MD5 ist keine gute Idee, aber wie sieht es mit SHA-2 aus? Das ist laut Wikipedia noch sicher, SHA-3 wäre wohl am besten, aber dafür gibt es noch relativ wenige Bibliotheken. Oder welche Hashfunktion würdest du dann empfehlen?

Legend

Alter Hase

Beiträge: 731

Beruf: Softwareentwickler

  • Private Nachricht senden

23

29.03.2014, 15:09

Also zu SHA-2, damals als ich Kryptographie gehört hatte, wurde von SHA-1 schon abgeraten und zu SHA-256 als Bestandteil der SHA-2 Familie wurde gesagt, das es womöglich Aufgrund seiner Größe (halt 256 Bit ...) noch sicher sei. Heute sieht es aber doch schon schwer mitgenommen aus, so das ich dir da nicht zustimmen kann. Wenn ich auf http://en.wikipedia.org/wiki/SHA-2 "A 2011 attack breaks preimage resistance for 57 out of 80 rounds of SHA-512, and 52 out of 64 rounds for SHA-256." lese, kann ich nur sagen: Das sind die Anzeichen, das deren Zeit zuende gehen wird.

Und okay, ich war etwas ungenau als ich SHA-Familie sagte. SHA-3 scheint brandneu zu sein und teilt sich mit den vorherigen Algorithmen nur den Namen.

Also wenn SHA-2, dann SHA-512. Das wird wohl noch am längsten durchhalten.
"Wir müssen uns auf unsere Kernkompetenzen konzentrieren!" - "Juhu, wir machen eine Farm auf!"

Netzwerkbibliothek von mir, C#, LGPL: https://sourceforge.net/projects/statetransmitt/

MitgliedXYZ

Alter Hase

  • »MitgliedXYZ« ist der Autor dieses Themas

Beiträge: 1 369

Wohnort: Bayern

  • Private Nachricht senden

24

29.03.2014, 15:24

@Legend
Da in den Standard Java Bibliotheken schon SHA-2 mitgeliefert wird, werde ich erst mal das verwenden. Ich kann es ja später immer noch austauschen. Und ein unbekanntes Programm wird wohl für Angriffe nicht so interessant sein...

Es gibt keinen Hashalgorithmus, bei dem keine Kollisionen existieren (sie sind surjektiv). Die Frage ist, wie schwer es ist, eine Kollision zu finden.
Weil ich das gerade lese, Hashfunktionen müssen nicht surjektiv sein, gute Funktionen sind es zwar meistens, aber sie müssten lediglich injektiv sein. Da die Hashwerte normalerweise von fester länge sind, ist es logisch das Kollisionen auftreten müssen.

Legend

Alter Hase

Beiträge: 731

Beruf: Softwareentwickler

  • Private Nachricht senden

25

29.03.2014, 15:33

Ja, Austauschbarkeit ist generell eine gute Idee. Wer weiß, vielleicht ist SHA-3 in 10 Jahren unsicher? Und manche Software ist länger im Einsatz als man zuerst glauben mag! Man denke nur an den ganzen Aufwand vorm Jahr 2000 ...
"Wir müssen uns auf unsere Kernkompetenzen konzentrieren!" - "Juhu, wir machen eine Farm auf!"

Netzwerkbibliothek von mir, C#, LGPL: https://sourceforge.net/projects/statetransmitt/

26

29.03.2014, 15:50

Weil ich das gerade lese, Hashfunktionen müssen nicht surjektiv sein, gute Funktionen sind es zwar meistens, aber sie müssten lediglich injektiv sein. Da die Hashwerte normalerweise von fester länge sind, ist es logisch das Kollisionen auftreten müssen.

Sorry, ich meinte natürlich Hashfunktionen sind nicht injektiv. Da hab ich wohl schneller geschrieben als gedacht.
"Theory is when you know something, but it doesn’t work. Practice is when something works, but you don’t know why. Programmers combine theory and practice: Nothing works and they don’t know why." - Anon

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

27

29.03.2014, 19:57

Bei dem ganzen Gerede über Unsicherheit der Hashfunktionen sollte man aber bitte auch bedenken, dass man da auch erstmal eine valide Nachricht zu bauen können muss, die eine entsprechende Hash-Kollision erzeugt. Eine beliebige zu bauen mag bezüglich der Sicherheit des Hashs ja vielleicht noch im Rahmen des möglichen liegen, aber eine Nachricht zu bauen, die einen Hash besitzt, der für einen Angriff passt, das ist oft schon wieder eine ganz andere Geschichte. Vor allem, wenn die Nachricht eben an eine gewisse Syntax *und* Semantik gebunden ist, die man validieren kann (und ohnehin immer sollte).
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

28

30.03.2014, 11:45

So ist es. Es geht hier ja um Signierung von Nachrichten und nicht um das Speichern von Passwörtern in einer Datenbank. Für letztere Sachen gibt es spezielle adaptive Hash-Funktionen, denen man einen "Arbeitsfaktor" übergeben kann (siehe https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet). Zur Signierung von Nachrichten reicht auf jeden Fall SHA-1.
@MitgliedXYZ: Du solltest Dir mal Spezifikationen wie OAUTH anschauen (dort wird bei jedem Request auch ein HMAC mitgeliefert). Generell machen sich die Leute für RESTful Services Gedanken über Signierung. Bei normalen Webservices gibt es das natürlich auch, da ist das ganze innerhalb der WS-Security-Spezifikation standardisiert.

MitgliedXYZ

Alter Hase

  • »MitgliedXYZ« ist der Autor dieses Themas

Beiträge: 1 369

Wohnort: Bayern

  • Private Nachricht senden

29

03.04.2014, 18:34

Jetzt habe ich mal dieses RSA Tutorial gelesen und ausprobiert, aber wenn ich den Text wieder entschlüssele, sieht man den unteren Text, der eindeutig nicht mehr mit dem Original übereinstimmt. Hat jemand eine Idee, stimmt das Tutorial nicht?

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
// Encode the original data with RSA private key
        byte[] encodedBytes = null;
        try {
            Cipher c = Cipher.getInstance("RSA");
            c.init(Cipher.ENCRYPT_MODE, privateKey);
            encodedBytes = c.doFinal(theTestText.getBytes());
        } catch (Exception e) {
            Logfile.print("RSA encryption error");
        }
        TextView tvencoded = (TextView) findViewById(R.id.textView2Verschluesselt);
        tvencoded.setText("[ENCODED]:\n" +
                Base64.encodeToString(encodedBytes, Base64.DEFAULT) + "\n");

        // Decode the encoded data with RSA public key
        byte[] decodedBytes = null;
        try {
            Cipher c = Cipher.getInstance("RSA");
            c.init(Cipher.DECRYPT_MODE, publicKey);
            decodedBytes = c.doFinal(encodedBytes);
        } catch (Exception e) {
            Logfile.print("RSA decryption error");

        }

        String entschluesseltText = Base64.encodeToString(decodedBytes, Base64.DEFAULT);

        Toast.makeText(MainActivity.this, entschluesseltText, Toast.LENGTH_LONG).show();

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »MitgliedXYZ« (08.04.2014, 17:55)


Sacaldur

Community-Fossil

Beiträge: 2 301

Wohnort: Berlin

Beruf: FIAE

  • Private Nachricht senden

30

03.04.2014, 19:41

Mit RSA verschlüsselst du die Bytes deines String.
Diese lässt du dir dann Base64-kodiert ausgeben.
Danach entschlüselst du diese Bytes wieder und lässt sie dir ebenfalls Base64-kodiert ausgeben.
(Da kann gar nicht das gleiche rauskommen. ;) )
Spieleentwickler in Berlin? (Thema in diesem Forum)
---
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].

Werbeanzeige