String verschlüsseln - eigener Algorithmus

[Hag2bard]

package com.crypt;

import java.util.Random;


public class Crypt3 {
private String unencrypted;
private int length;
private StringBuilder randomKey;
private Random rnd = new Random();

public String encrypt(String unencrypted){
  this.unencrypted = unencrypted;
  this.length = unencrypted.length();
  getRandomKey(this.length);
  char[] unencryptedAsCharArray = this.unencrypted.toCharArray();
  for (int i=0; i<this.length; i++){
     unencryptedAsCharArray[i]+=randomKey.charAt(i);
  }
  return String.valueOf(unencryptedAsCharArray);
}

public StringBuilder getRandomKey(int length){
randomKey = new StringBuilder(this.length);
for (int i=0; i<length; i++){
  randomKey.append(rnd.nextInt(10));
  }
  return randomKey;
}
//decrypt

public String decrypt(String encrypted, String key){
char[] encryptedAsCharArray = new char[encrypted.length()];
encryptedAsCharArray = encrypted.toCharArray();
for (int i=0; i<encrypted.length(); i++){
  encryptedAsCharArray[i]-=key.charAt(i);
}
return String.valueOf(encryptedAsCharArray);
}

public StringBuilder getKey(){
  return randomKey;
}

}

 

[Mart]

Ohje hier hagelt es Kritik, nahezu Shitstorm. Tut mir leid dass ich ein Anfänger bin. Ich benutze eine IDE auf meinem Handy. Die Formatierung ist natürlich absolut für die Katz.
Ich verstehe schon was final bedeutet und was ein Zugriffsmodifikator ist. Ich dachte nur dass static Methoden/Variablen dafür da sind, dass ich von jeder anderen Klasse aus ohne eine Instanz von der Klasse mit den Statics erzeugen zu müssen auf diese zugreifen

Es ist kein shitstorm

Es ist sogar beeindruckend dass jemand auf einem Handy jemand es schafft java zu programmieren

 

[mihe7]

Ohje hier hagelt es Kritik, nahezu Shitstorm.

Pfff, Shitstorm, wegen der paar Leerzeichen.

Ich benutze eine IDE auf meinem Handy.

Wer macht denn sowas? Mir graut vor jeder Eingabe auf den Dingern.

EDIT: Oops, da war noch eine zweite Seite...

 

[Hag2bard]

Einen eigenen Schlüssel angeben zu können habe ich weggelassen. Die Methode getRandomKey wollte ich deshalb so schreiben, damit man sie wieder verwenden kann. Dabei dachte ich an das Prinzip der Wiederverwendbarkeit. Aber dass ich von dieser Methode auf eine Instanzvariable zugreife, ist höchst ungünstig. Ich weiß aber noch nicht wie ich es verändern könnte.
Manchmal muss man eine Nacht drüber schlafen um dann alles über den Haufen zu werfen.
Welche Vorteile bietet es denn den Scanner static zu machen? Dann frag ich mal so.
Ich dachte sowas zu vermeiden ist das ein und alles.

 

[temi]

Ohje hier hagelt es Kritik, nahezu Shitstorm.

Auf gar keinen Fall! Du möchtest dich verbessern und bekommst Unterstützung dazu. Bitte auf keinen Fall anders auffassen!

 

[Hag2bard]

Ok also nochmal für mich zum Mitschreiben.
Ich habe den Code gerade geändert(morgendlicher Spaziergang mit Handy in der Hand😁 ) und muss sagen, im Grunde genommen brauche ich gar keine Instanzvariablen.
Ein zu verschlüsselnder String wird übergeben, zurück kommt ein Key und der verschlüsselte String. Das wars. Beim Entschlüsseln übergebe ich den verschlüsselten String und den Key und fertig.
(Kurzer Zwischenwurf zu Random: Habe ich das hier eventuell mehrmals mit dem Scanner verwechselt?)

Hier mein neuer Code. Das Random brauche ich nur ein einziges mal in einer Methode, muss er auch eine Instanzvariable sein?

package com.crypt;

import java.util.Random;


public class Crypt3 {
private final Random rnd = new Random();

public String encrypt(String unencrypted){
  String randomKey = getRandomKey(unencrypted.length());
  char[] unencryptedAsCharArray = unencrypted.toCharArray();
  for (int i=0; i<unencrypted.length(); i++){
     unencryptedAsCharArray[i]+=randomKey.charAt(i);
  }
  return String.valueOf(unencryptedAsCharArray);
}

public String getRandomKey(int length){
StringBuilder randomKey = new StringBuilder(length);
for (int i=0; i<length; i++){
  randomKey.append(rnd.nextInt(10));
  }
  return randomKey.toString();
}

public String decrypt(String encrypted, String key){
char[] encryptedAsCharArray = new char[encrypted.length()];
encryptedAsCharArray = encrypted.toCharArray();
for (int i=0; i<encrypted.length(); i++){
  encryptedAsCharArray[i]-=key.charAt(i);
}
return String.valueOf(encryptedAsCharArray);

}

}

 

[mihe7]

Das Random brauche ich nur ein einziges mal in einer Methode, muss er auch eine Instanzvariable sein?

Nein.

 

[temi]

Ich dachte nur dass static Methoden/Variablen dafür da sind, dass ich von jeder anderen Klasse aus, ohne eine Instanz von der Klasse mit den Statics erzeugen zu müssen auf diese zugreifen kann.
Das hat sich meiner Meinung nach widersprochen wenn man sie dann private macht.

Das ist im Großen und Ganzen auch richtig, auch wenn die Begründung "von überall darauf zugreifen" zumindest "Geschmack" hat. In der Regel ist das einzige "static" im Programm vor der Methode main(), aber es gibt natürlich Gründe, warum es sinnvoll sein kann etwas "static" zu machen.

Einer davon wäre die Konstante, die in Java üblicherweise so deklariert und definiert wird:

public class Foo {
   
    private final static int ZWEIUNDVIERZIG = 42;
   
   
    // ...
}

Konstanten werden per Konvention komplett groß geschrieben, ob sie public oder private ist kommt darauf an, ob man die Konstante nur innerhalb der Klasse benötigt oder auch für den Zugriff von außen freigeben möchte. Die Java-Klasse Integer bietet hier z. B. die Konstante MAX_VALUE an: https://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html#field_summary

Manchmal begegnet einem die Aufgabe, zu zählen, wie viele Instanzen von einer Klasse erzeugt wurden:

public class CountInstances {
   
    private static int counter = 0;
   
    public CountInstances() {
        counter++;
    };
   
    public static int getCounter() {
        return counter;
    }
}

Die Klassenvariable "counter" gibt es für die Klasse nur einmal, sie zählt die erzeugten Instanzen.

 

[Hag2bard]

Ok super dann weiß ich dahingehend Bescheid.
Ganz schön schwere Geburt für 34 Zeilen Code

 

[temi]

zurück kommt ein Key und der verschlüsselte String

Hier hast du ein kleines Problem, denn die Rückgabe der Methode ist der verschlüsselte Text und der verwendete Key ist unbekannt. Das macht das Entschlüsseln schwierig.

 

[Hag2bard]

Super das freut mich, eine kleine Herausforderung. entweder ganz simpel ein String Array zurückgeben mit einem Index von 2 oder ein Objekt. An solch eine Problematik dachte ich sschon einmal aber ich löste dies mit Instanzvariablen.

 

[Mart]

Welche Vorteile bietet es denn den Scanner static zu machen? Dann frag ich mal so.

Es ist ein riesen Unterschied ob du static alleine machst oder ein static final machst

das Problem bei static alleine ist dass du von irgendeiner anderen klasse aus das ganze verändern kansnt und sich am ende bei 20 Klassen die auf die gleiche Variable zugreifen du nicht mehr weist wer wo was ändert = spaghetti code

bei static final gibts das Problem nicht weil man es durch das Final nicht mehr ändern kann
zb Math.PI ist eine static final konstante und schon ewig in Java und auch kein Problem dass es static ist weil es auch final ist -> egal wo du es hernimmst es ist immer 3.14.... -> kein spaghetti Code

der Vorteil ist beim Code lesen bei static final -> der der es lesen muss muss sich keine Gedanken machen über die Veränderung von dem weil es nicht verädnert werden kann

 

[temi]

Super das freut mich, eine kleine Herausforderung. entweder ganz simpel ein String Array zurückgeben mit einem Index von 2 oder ein Objekt. An solch eine Problematik dachte ich sschon einmal aber ich löste dies mit Instanzvariablen.

Würde beides funktionieren, wobei die erste Möglichkeit nicht so schön ist. Du gibst ein Array mit zwei Elementen zurück und der Benutzer der Klasse muss nun wissen, welcher Inhalt an welcher Stelle steckt. Das ist eher suboptimal und zu vermeiden. Alternativ könnte man hier eine eigens dafür vorgesehene Klasse zurückgeben, die über entsprechende Getter Zugriff auf Text und Schlüssel ermöglicht.

Ein Instanzvariable für den letzten erzeugten Schlüssel mit einer entsprechenden Getter-Methode, halte ich da für sinnvoller. Würde man allerdings vergessen den Schlüssel zwischen zwei Verschlüsselungen auszulesen, dann ist das blöd.

Am besten finde ich allerdings immer noch die Variante den Schlüssel der Methode als Parameter mitzugeben, wie du es beim Entschlüsseln machst.

 

[Hag2bard]

Die Objektvariante:

package com.crypt;

public class Crypted {
  private final String ENCRYPTED;
  private final String KEY;

  public void setKey(String key) {
    this.KEY = Key;
  }

  public String getKey() {
    return this.KEY;
  }

  public void setEncrypted(String encrypted) {
    this.ENCRYPTED = encrypted;
  }

  public String getEncrypted() {
    return THIS.UNENCRYPTED;
  }
}

 

[mihe7]

Am besten finde ich allerdings immer noch die Variante den Schlüssel der Methode als Parameter mitzugeben, wie du es beim Entschlüsseln machst.

Ich finde eine Instanzvariable für den Schlüssel besser. So muss man bei jedem Ver-/Entschlüsselungsvorgang den Schlüssel kennen und mitgeben.

 

[temi]

Es ist ein riesen Unterschied ob du static alleine machst oder ein static final machst

das Problem bei static alleine ist dass du von irgendeiner anderen klasse aus das ganze verändern kansnt und sich am ende bei 20 Klassen die auf die gleiche Variable zugreifen du nicht mehr weist wer wo was ändert = spaghetti code

Das trifft natürlich nur zu, wenn die entsprechende Variable überhaupt sichtbar ist. Generell könnte man allerdings die Regel formulieren, dass man erst mal möglichst alles final machen sollte, um ungewolltes Überschreiben zu verhindern. Nur das, was wirklich nicht immutabel sein muss, wird davon ausgenommen. Ein Tipp von Bloch (in Effective Java) ist auch, dass Klassen möglichst unveränderbar sein sollten.

Das sieht man häufig auch bei Methodenparametern (ich mach das auch so):

public void someMethod(final int someParameter) {
    
    // ...
    
    someParameter = 42; // geht nicht!
}

Parameter sollten i.d.R. nicht verändert werden und damit schützt man sich in gewisser Weise davor, das versehentlich zu machen.

 

[Mart]

Die Objektvariante:

package com.crypt;

public class Crypted {
  private final String ENCRYPTED;
  private final String KEY;

  public void setKey(String key) {
    this.KEY = Key;
  }

  public String getKey() {
    return this.KEY;
  }

  public void setEncrypted(String encrypted) {
    this.ENCRYPTED = encrypted;
  }

  public String getEncrypted() {
    return THIS.UNENCRYPTED;
  }
}

dein Editor macht mich ganz porös...dass ein Tab und die Einrückung nicht 4 Leerzeichen hat macht mich ganz nervös


was du noch zusätzlcih einbauen könntest zum lernen ist es dass du statt einen String encrypted eine Liste hast die man mit Strings befüllen kann und bie encrypt wird dann die ganze Liste mit dem Key verschlüsselt ( das hätte zufolge dass man das braucht was @temi sagte dass man nicht immer den schlüssel sofort ändert )

du weist aj wie man mit arrays umgeht das sieht man ja dass du das kannst
es wäre halt meines erachtens "gut" wenn man auch mal andere Strukturen auch mal anschaut und ausprobiert

 

[temi]

Ich finde eine Instanzvariable für den Schlüssel besser. So muss man bei jedem Ver-/Entschlüsselungsvorgang den Schlüssel kennen und mitgeben.

Ja, wenn es darauf ausgelegt ist, dass bei jeder Verschlüsselung ein neuer zufälliger Schlüssel verwendet wird, hast du wohl recht. Irgendwo am Anfang hat @Hag2bard geschrieben, dass er den Schlüssel täglich einmal mit seinem Kommunikationspartner austauschen möchte, dass wäre dann schwierig.

 

[Mart]

Das trifft natürlich nur zu, wenn die entsprechende Variable überhaupt sichtbar ist. Generell könnte man allerdings die Regel formulieren, dass man erst mal möglichst alles final machen sollte, um ungewolltes Überschreiben zu verhindern. Nur das, was wirklich nicht immutabel sein muss, wird davon ausgenommen. Ein Tipp von Bloch (in Effective Java) ist auch, dass Klassen möglichst unveränderbar sein sollten.

Das sieht man häufig auch bei Methodenparametern (ich mach das auch so):

public void someMethod(final int someParameter) {
  
    // ...
  
    someParameter = 42; // geht nicht!
}

Parameter sollten i.d.R. nicht verändert werden und damit schützt man sich in gewisser Weise davor, das versehentlich zu machen.

deswegen wollte ich bei meinem Code den Random Generator static final machen
1. du hast ihn nie verändert
2. eig sollte der auch nie verändert werden sollte ja nur die nextInt mehtode bereitstellen
3. du brauchst nur 1en davon .. jedes crypt braucht ja nicht seinen eigenen generator

 

[temi]

Die Objektvariante:

package com.crypt;

public class Crypted {
  private final String ENCRYPTED;
  private final String KEY;

  public void setKey(String key) {
    this.KEY = Key;
  }

  public String getKey() {
    return this.KEY;
  }

  public void setEncrypted(String encrypted) {
    this.ENCRYPTED = encrypted;
  }

  public String getEncrypted() {
    return THIS.UNENCRYPTED;
  }
}

Setter würde ich, wo immer möglich, vermeiden. Die Veränderung des Zustands eines Objektes sollte immer über, ich nenne sie mal, fachliche Methoden erfolgen, z. B.

public class Car {
    
    private int speed;
    
    public void accelerate() { // Auto wird beschleunigt
        speed++;
    }
}

In Fall der Klasse Crypted lieber einen passenden Konstruktor erstellen. Hier ist die Regel: Nach der Erzeugung eines Objektes sollte das Objekt in einem Zustand sein, dass es direkt verwendet werden kann.

 

[Hag2bard]

Sehr gut du nimmst mir meine nächste Frage vorweg.
Ich werde die setter vermeiden und in Methoden final verwenden.

 

[mihe7]

Ja, wenn es darauf ausgelegt ist, dass bei jeder Verschlüsselung ein neuer zufälliger Schlüssel verwendet wird, hast du wohl recht.

Nein, ich meinte etwas wie

public class Crypt {
    private final String key;
    
    public Crypt(String key) { this.key = key; }
    // ...
}

 

[temi]

deswegen wollte ich bei meinem Code den Random Generator static final machen
1. du hast ihn nie verändert
2. eig sollte der auch nie verändert werden sollte ja nur die nextInt mehtode bereitstellen
3. du brauchst nur 1en davon .. jedes crypt braucht ja nicht seinen eigenen generator

Alles richtig. Ich würde den Generator vermutlich ebenfalls als Instanz- oder Klassenvariable implementieren.

 

[mihe7]

Ich würde den Generator vermutlich ebenfalls als Instanz- oder Klassenvariable implementieren.

Ich auch, schon aus Gründen der Testbarkeit (Konstruktor). Die Frage wäre, ob man den Key-Generator nicht gar in eine eigene Klasse auslagert (irgendwie beschleicht mich gerade das Gefühl, dass wir hier die Crypto-API nachbauen)

 

[temi]

Ich auch, schon aus Gründen der Testbarkeit (Konstruktor). Die Frage wäre, ob man den Key-Generator nicht garin eine eigene Klasse auslagert (irgendwie beschleicht mich gerade das Gefühl, dass wir hier die Crypto-API nachbauen)

public interface KeyGenerator {
    String getRandomKey();
}

Dann aber auch mit einem passenden Interface!

 

[Mart]

public interface KeyGenerator {
    String getRandomKey();
}

Dann aber auch mit einem passenden Interface!

die Java doc kommentare nicht vergessen!

 

[temi]

@Hag2bard du erkennst: Man kann mal einfach drauf los programmieren und wird vermutlich auch ein funktionsfähiges Ergebnis erhalten, aber sauberer Code (Clean Code, danach kannst du auch mal suchen) erfordert noch einiges mehr. Es gibt sogar eine Initiative dazu: https://clean-code-developer.de

@mihe7 hat ja bereits die Testbarkeit angesprochen und @Mart hat richtig auf die Dokumentation hingewiesen, wobei damit keine Kommentare innerhalb des Codes gemeint sind. Anstelle derer, sollte man dafür sorgen, dass der Code an sich, u. a. durch gut gewählte Bezeichner, selbstkommentierend wird. Er meinte Javadoc, der zumindest für die Klasse und alle öffentliche Methoden erstellt werden sollte.

Es wurden schon viele "Regeln" erwähnt und es gibt noch viel mehr. Aber keine Sorge, dass merkt man sich mit der Zeit, immer langsam mit den Pferden.

 

[temi]

Welche Vorteile bietet es denn den Scanner static zu machen? Dann frag ich mal so.
Ich dachte sowas zu vermeiden ist das ein und alles.

Um vielleicht noch darauf einzugehen. Ich nehme allerdings an, du meinst "Random", denn ich sehe in dem Programm keinen Scanner.

Wenn du eine neue Instanz von Random erzeugst, dann wird dazu immer auch ein Seed benötigt. Das ist so eine Art Startwert. Verwendest du den Konstruktor ohne Parameter, dann wird mit jeder erzeugten Instanz versucht einen neuen mehr oder weniger zufälligen Seed zu verwenden. Es gibt noch einen zweiten Konstruktor, bei dem man den Wert für den Seed angeben kann. Jede Instanz die mit dem selben Seed erzeugt wurde, erzeugt immer die gleiche Folge von Zufallszahlen. Siehe auch: https://docs.oracle.com/javase/8/docs/api/java/util/Random.html#Random--
Theoretisch könnte es beim parameterlosen Konstruktor von Random passieren, dass sehr kurz hintereinander erzeugte Instanzen den gleichen Seed erhalten und damit auch die gleiche Zufallsfolge erzeugen. Das kann wichtig sein oder auch egal - das hängt von der Anwendung ab.

Den Unterschied statisch - nicht statisch kennst du. Eine statische Variable gehört zur Klasse und jede erzeugte Instanz der Klasse greift auf die selbe statische Variable zu. Bei einer nicht statischen Variablen gibt es diese für jede erzeugte Instanz der Klasse.

Hast du also einen nicht statischen Zufallsgenerator in deiner Klasse, dann wird für jede neu erzeugte Instanz dieser Klasse ein separater Zufallsgenerator erzeugt. Im anderen Fall wird der Zufallsgenerator nur einmal erzeugt. Ob das eine oder das andere gewünscht ist, hängt von der Anwendung ab. Ich würde sagen, in deinem Fall ist es egal.

 

[Hag2bard]

Ich würde auch sagen dass es in meinem Fall egal ist, aber was wäre denn sicherer?
Und ist es besser dem Random Konstruktor einen Seed wie System.currentTimeMillis() mitzugeben oder ist der Standardkonstruktor besser?
Da ich Interfaces üben sollte, hatte dazu ja schon mal einen Beitrag erstellt, möchte ich dies gerne mal ausprobieren.

 

[Mart]

Ich würde auch sagen dass es in meinem Fall egal ist, aber was wäre denn sicherer?

"sicherer" ist das final static... aber das ist eine absicherung gegen leute die dann mit deinem Code arbeiten dass es nicht fehlerhaft verändert wird

und wie schon mal gesagt... so viel final machen wie möglich ist


ausserdem nur 1 Objekt generator zu haben macht auch meines Erachtens mehr sinn

 

[temi]

Und ist es besser dem Random Konstruktor einen Seed wie System.currentTimeMillis() mitzugeben oder ist der Standardkonstruktor besser?

Weiß nicht, ob man da besser sagen kann. Einen Seed mitzugeben ist sinnvoll, wenn man eine reproduzierbare Folge von Zufallszahlen haben möchte.

"sicherer" ist das final static... aber das ist eine absicherung gegen leute die dann mit deinem Code arbeiten dass es nicht fehlerhaft verändert wird

Da der Zufallszahlengenerator privat ist, sehe ich dieses konkrete Problem nicht unbedingt, wobei "final" sinnvoll ist.

 

[Mart]

Weiß nicht, ob man da besser sagen kann. Einen Seed mitzugeben ist sinnvoll, wenn man eine reproduzierbare Folge von Zufallszahlen haben möchte.

Da der Zufallszahlengenerator privat ist, sehe ich dieses konkrete Problem nicht unbedingt, wobei "final" sinnvoll ist.

der Generator war private weil ich weiter oben schon erwähnt hatte dass Vererbung mit protected bis jetzt komplett unterschlagen wurde... vllt kommt da noch ein Protected hin ... vllt kommt es auch ins interface wer weis wo es den TE noch so hintreibt

 

[temi]

der Generator war private weil ich weiter oben schon erwähnt hatte dass Vererbung mit protected bis jetzt komplett unterschlagen wurde... vllt kommt da noch ein Protected hin ... vllt kommt es auch ins interface wer weis wo es den TE noch so hintreibt

Naja, mit der Argumentation in Zusammenhang mit

"sicherer" ist das final static

müssen wir jetzt immer alle Instanzvariablen zu finalen Klassenvariablen machen.

Die Regel lautet, dass eine Klasse soviel wie möglich verbergen sollte und nur das, was wirklich unbedingt notwendig ist, nach außen geben sollte. Das macht man nun mal mit den Sichtbarkeitsmodifizierern.

Über Vererbung sprachen wir bisher ja noch nicht, aber da gilt üblicherweise:

Entwerfe eine Klasse für Vererbung oder verbiete sie und ziehe Komposition der Vererbung vor.

 

[temi]

Da ich Interfaces üben sollte, hatte dazu ja schon mal einen Beitrag erstellt, möchte ich dies gerne mal ausprobieren.

Mach das. Hast du bereits eine Idee dazu?

 

[Hag2bard]

So langsam wird der Thread hier echt riesig. Nochmals vielen Dank für die rege Beteiligung.
Hier mal mein Zwischenstand:

[CODE lang="java" title="Klasse Crypt3"]package com.crypt;

import com.crypt.IKeyGenerator;

public class Crypt3 {


public Crypted encrypt(final String unencrypted){
IKeyGenerator keyGenerator = new KeyGenerator();
String randomKey = keyGenerator.getRandomKey(unencrypted.length());
char[] unencryptedAsCharArray = unencrypted.toCharArray();
for (int i=0; i<unencrypted.length(); i++){
unencryptedAsCharArray+=randomKey.charAt(i);
}
Crypted crypted = new Crypted(String.valueOf(unencryptedAsCharArray), randomKey);
//return String.valueOf(unencryptedAsCharArray);
return crypted;
}


public String decrypt(final String encrypted, final String key){
char[] encryptedAsCharArray = new char[encrypted.length()];
encryptedAsCharArray = encrypted.toCharArray();
for (int i=0; i<encrypted.length(); i++){
encryptedAsCharArray-=key.charAt(i);
}
return String.valueOf(encryptedAsCharArray);
}
}
[/CODE]

[CODE lang="java" title="Klasse Crypted"]package com.crypt;

public class Crypted {
private final String ENCRYPTED;
private final String KEY;

public Crypted(final String encrypted, final String key) {
this.ENCRYPTED = encrypted;
this.KEY = key;
}

public String getKey() {
return this.KEY;
}

public String getEncrypted() {
return this.ENCRYPTED;
}
}
[/CODE]

[CODE lang="java" title="Interface IKeyGenerator"]package com.crypt;

public interface IKeyGenerator {
String getRandomKey(final int length);
}
[/CODE]

[CODE lang="java" title="Klasse KeyGenerator"]package com.crypt;

import java.util.Random;

public class KeyGenerator implements IKeyGenerator{

private static final Random RANDOMGENERATOR = new Random();

public String getRandomKey(final int length) {
StringBuilder randomKey = new StringBuilder(length);
for (int i = 0; i < length; i++) {
randomKey.append(RANDOMGENERATOR.nextInt(10));
}
return randomKey.toString();
}
}
[/CODE]

Bei dem Interface und vor allem der Namensvergabe brauch ich noch Nachhilfe.

 

[Mart]

vor allem der Namensvergabe brauch ich noch Nachhilfe.

Aus meiner Arbeit hat einer erzählt dass sich immer alle darüber aufgeregt haben dass er zu lange namen für Variablen benutzt hat... nur sein Code war halt einwandfrei lesbar weil man durch die Namen wusste um was es geht also da eher lieber länger als zu kurz


Da du erst anfängst mit dem Arbeiten und das hatte ich dir im anderen Thread auch schon gesagt... schreib den Code so klar wie möglich weil du wirst extrem viel hilfe brauchen in der Arbeit und die bekommst du auch nur derjenige der dir hilft tut sich dann 10 mal einfacher eine Lösung zu finden und dir auch einfacher erklären kann warum und weshalb und dann läuft allles geschmeidiger

 

[temi]

Ich bin mir nicht sicher, wo das hier noch hinführt

Das ist doch gar nicht schlecht, aber was man vermeiden sollte ist dieses hier:

public Crypted encrypt(final String unencrypted){
    IKeyGenerator keyGenerator = new KeyGenerator();

Da hast du die Abhängigkeit zur konkreten Implementation von IKeyGenerator (das Präfix I wird in Java nicht so benutzt, aber wenn es dir gefällt).

Der Clean Code Aspekt nennt sich Dependeny Injection und könnte ungefähr so aussehen:

public class Crypt {
 
    privat final IKeyGenerator keyGenerator;
 
    public Crypt(final IKeyGenarator keyGenerator) {
        this.keyGenerator = keyGenerator;
    }
 
    // ..
}

// und weiter

Crypt crypt = new Crypt(new KeyGenerator());

Damit wird die Abhängigkeit von außen in die Instanz gegeben (injiziert) und du kannst den KeyGenerator z. B. für das Testen austauschen ohne den Code der Klasse zu ändern.

Zur Namensgebung vielleicht im Speziellen:

Interface KeyGenerator und die Klasse im einfachsten Fall KeyGeneratorImpl. Man würde die konkrete Implementation normalerweise so bezeichnen, dass der Name ausdrückt, was die Implementation besonders auszeichnet.

Beispiele wären das Interface List und die Implementation ArrayList, die intern ein Array verwendet oder die Implementation LinkedList, die eine verkettete Liste darstellt.

 

[Hag2bard]

Ich dachte das wäre eine Konvention.

 

[temi]

Ich dachte das wäre eine Konvention.

Was jetzt? Der Präfix I von dem Interface? In C# ist das tatsächlich eine Konvention, in Java eher nicht.

 

[temi]

Was mir grad so aufgefallen ist. Du gehst derzeit immer davon aus, dass der Schlüssel genauso lang ist, wie der zu verschlüsselnde Text. Bei langen Texten ist das nicht so schön. Versuch doch mal den Code für die Ver- und Entschlüsselung so zu ändern, dass er mit kürzeren Schlüsseln auskommt (z. B. durch Wiederholung des Schlüssels). Das macht es auch einfacher einen persönlichen Schlüssel oder einen fixen Testschlüssel zu verwenden.

 

[Mart]

und as mit meiner schnuckligen liste ist auch noch nicht drin

 

[Hag2bard]

Stimmt da muss ich noch dran arbeiten.

 

[Hag2bard]

Ich bin soweit.

[CODE lang="java" title="Klasse crypt3"]package com.crypt;

import com.crypt.IKeyGenerator;



public class Crypt3 {
private int LENGTH=8;

public Crypted encrypt(final String unencrypted){
IKeyGenerator keyGenerator = new KeyGenerator();
if (unencrypted.length()<this.LENGTH){this.LENGTH=unencrypted.length();}
String randomKey = keyGenerator.getRandomKey(this.LENGTH);
char[] unencryptedAsCharArray = unencrypted.toCharArray();
int j=0;
for (int i=0; i<unencrypted.length(); i++){
unencryptedAsCharArray+=randomKey.charAt(j);
System.out.println ("j= "+j);
if (j<this.LENGTH-1){j++;}
else {j=0;}
}
Crypted crypted = new Crypted(String.valueOf(unencryptedAsCharArray), randomKey);
//return String.valueOf(unencryptedAsCharArray);
return crypted;
}


public String decrypt(final String encrypted, final String key){
char[] encryptedAsCharArray = new char[encrypted.length()];
encryptedAsCharArray = encrypted.toCharArray();
int j=0;
for (int i=0; i<encrypted.length(); i++){
encryptedAsCharArray-=key.charAt(j);
if (j<this.LENGTH-1){j++;}
else {j=0;}
}
return String.valueOf(encryptedAsCharArray);
}
}
[/CODE]

Und ich hoffe das mit der Liste habe ich richtig verstanden

[CODE lang="java" highlight="20-26" title="Main"]package com.crypt;

import com.crypt.Crypt3;
import com.crypt.Crypted;


public class Ma {
public static void main(String[] args) {
Crypt3 c = new Crypt3();
Crypted crypted = c.encrypt("Zu verschluesselnder Text der echt lang ist");
System.out.println (crypted.getKey() + " \n" + crypted.getEncrypted());
String iu= c.decrypt("¨Y©¢ª®££¡£¥P©S¢P§YU¦", "53930075");
System.out.println (iu);
iu=c.decrypt("§Y¬ª¥®ª«¡¤¨WªR©X¦Y¢¦U¥", "62967825");
System.out.println (iu);
iu=c.decrypt("¡©¯", "6875");
System.out.println (iu+ "h");
Crypted crypted2 = c.encrypt("kurz");
System.out.println (crypted2.getKey()+" \n"+ crypted2.getEncrypted());
Crypted[] cryptedArray = new Crypted[4];
cryptedArray[0]=c.encrypt("Test");
cryptedArray[1]=c.encrypt("Test");
cryptedArray[2]=c.encrypt("Test");
cryptedArray[3]=c.encrypt("Test");
for (int i=0;i<4;i++){
System.out.println (cryptedArray.getKey() + " \n" + cryptedArray.getEncrypted());
}

}

}
[/CODE]

Die Main ist natürlich nur zum testen, deshalb so chaotisch.

Ich hätte noch 3 Fragen: kann ich eine Variable zur Laufzeit final machen?

Kann ich beeinflussen, dass der Verschlüsselte String im Alphabet bleibt?

Diese Vierecke sind unterschiedlich werden aber immer gleich dargestellt. Gibt es eine Möglichkeit System.out.println dazu zu bewegen dies anders auszugeben?

 

[berndoa]

Hallo und guten Abend,

Ich möchte einen String verschlüsseln, so dass man ihn nur mit einem Key wieder entschlüsseln kann. Ich weiß dass es dafür Bibliotheken gibt, die das ganze wahrscheinlich viel besser machen können als ich, aber darum geht es mir nicht.
Mir geht es darum eine simple Verschlüsselung zu entwickeln. Leider habe ich keinerlei Lösungsansätze und bräuchte einen Denkanstoss.
Meine Idee wäre einen String in ein char Array umzuwandeln und die einzelnen chars dann mit Hilfe des Schlüssels zu verändern.
Aber wie ich das anstellen soll, da fehlt es mir an Ideen.

Vielleicht könnte der Schlüssel ein einfacher int Wert sein der lediglich die chars mit diesem multipliziert.
Wie ich die chars in bytecode oder hexcode umwandel, muss ich mir selber raussuchen.

Welche Ideen hättet ihr für einen Anfänger?

Danke im Voraus

Random Idee:
für eine Zahl k wendest du auf die Zeichen eines String sfolgendes an:
das 1. zeichen wird um k stellen nach rechts verschoben (also statt bei index=0 wird es zukünftig bei index=0+k=k sein)
UND es wird wie bei der cäsarvershclüsselung um k buchstaben verringert. (also mit k=3 wird aus einem E dann ein B).
Also wir verschieben die position um +k stellen und cäsardrehen den buchstaben um -k.

für das 2. zeichen machen wir dasselbe, nur dass wir nun die gegenteilige polarität machen.
also verschiebeung um -k stellen und buchstabendrehen um +k.
3. zeichen wieder position +k und bcuhstabendrehen -k.
und das halt für jedes zeichen im char array einmal.

so also ein durchgang des algorithmus für eine vorgegebene zahl k.


nun hast du einen schlüssel bestehend aus ganzen zahlen.
sagen wir bsopw schlüssel=1854

dann nimms du deinen unvershclüsselten string und wendest erst obigen algorithmus mit k=1 drauf an, dann obigen algorithmus auf das ergebnis mit k=8, dann mit k=5 und am ende nochmal mit k=4.

Ohne den schlüssel zu kennen wirst du nicht erraten können was der ursprungsstring war.
und falls man den key kennt, lässt es sich zurücktransformieren

 

[Hag2bard]

Ich bin gerade am Überlegen wie man eine Klasse gestalten könnte, die ein eingegebenes Passwort auf Richtigkeit überprüft.
Die Frage ist, ob ich durch Kapselung genug Sicherheit bekomme, dass ich ein zu prüfendes Passwort mit einer simplen equals Methode auf Richtigkeit überprüfen kann.
Wahrscheinlich müsste ich darauf achten dass man von der Klasse nicht erben kann, sodass man die Methoden nicht überschreiben kann.

Oder man speichert das Passwort nicht in Klartext sondern lediglich das verschlüsselte Passwort und einen Algorithmus, der dann das eingegebene Passwort verschlüsselt und das mit dem gespeicherten verschlüsselten Passwort prüft.

Auch da wäre es wichtig eine Vererbung zu vermeiden.
Ich glaub das ging mit abstrakten Klassen oder?
Kann ich eine .class Datei entschlüsseln?

 

[kneitzel]

Bei Passwörtern wird in er Regel ein Verfahren benutzt, das nicht entschlüsselbar ist.

Passwort -> verschlüsseln -> Verschlüsselten Text speichern.

Bei der Kontrolle geht es dann ebenso - und es wird dann am Ende der verschlüsselte Text verglichen.

Damit nicht immer bei einem Passwort überall das Gleiche verschlüsselte Passwort gespeichert wird (Dann wäre es zu einfach, über Wörterbücher zu entschlüsseln) gibt es meist noch einen Wert auf jedem System, mit dem das Ergebnis beeinflusst wird (oft SALT genannt).

Stichwort ist Password Hashing wäre da ein Stichwort. Auf die Schnelle habe ich diese Seite gefunden, die das erläutert (Habe ich mir aber nicht im Detail angesehen um sie zu bewerten): https://aware7.de/blog/password-hash-infografik/

Wenn Du eine Vererbung vermeiden willst, dann kannst Du eine Klasse final machen. Aber einen wirklichen Schutz gibt das nicht, denn das sind alles Dinge, die umgehbar sind.

Und ja - .class Dateien sind "dekompilierbar" und es gibt da diverse Decompiler für. Also wer den Code hat, der kann den lesen und auch verändern. Davor gibt es keinen Schutz.

 

[Mart]

d ja - .class Dateien sind "dekompilierbar" und es gibt da diverse Decompiler für. Also wer den Code hat, der kann den lesen und auch verändern. Davor gibt es keinen Schutz.

bei eclipse musst du nur den kompilierten text rein kopieren in den editor und dann hat man den dekompilierten code... inellij glaub ich kann es auch

 

[Hag2bard]

Wie sichert man seine Software denn dann ab?

 

[kneitzel]

Unter dem Strich: gar nicht.

Du kannst die Latte höher legen und es den Angreifern etwas schwerer machen, aber wirklich absichern kannst Du es nicht.

Eine gute Option ist, Code einfach nicht aus der Hand zu geben. Dann greifen Andere nur darauf zu (z.B. über den Webbrowser). Du erstellst also keine Software sondern Services.

Um die Latte höher zu legen: Du kannst dinge irgendwie versuchen zu schützen: Obfuscatoren, Code irgendwie verschlüsselt und wird dann über irgend welche Wege entschlüsselt und direkt in die VM geladen ... Gibt viele Wege, aber wirklich schützen kannst Du nichts, denn unter dem Strich muss der Code laufen auf dem Zielrechner. Und da kann man dann immer mit entsprechenden Tools alles abgreifen.

Und nicht zu vergessen: Du machst Dir und den Kunden das Leben schwerer. Obfuscatoren sind toll, nur eben bekommst du dann auch Stacktraces, bei denen Bezeichner unkenntlich gemacht wurden ... Oder Kunden haben Probleme, weil Dein Schutz nicht richtig läuft oder Aktivierungen sind notwendig oder oder oder ...

 

[LimDul]

Wie sichert man seine Software denn dann ab?

In dem man zuerst mal definiert, wogegen man sich absichern will. Vor welchen Angriffen / Problemen will man sich schützen?

Bei einer Verschlüsselungssoftware sollte es z.B. egal sein ob eine Person den Source Code kennt oder nicht.

Es ist immer wichtig zu definieren:
* Was ist der Angriffsvektor?
* Was sind die Informationen die geschützt werden?
* Vor wem sollen die geschützt werden?

Sonst ist es z:B. klar, wenn der Benutzer das Passwort in ein Eingabefeld eintippt, was dann verschlüsselt wird, dass man das Passwort nicht vor diesem Benutzer schützen muss.