Daten speichern ohne Datenbank

[Ingerten]

Hallo Männers, hab da mal ne frage.

Ich habe ein kleines Programm geschrieben, wo ich ein paar Einstellungen in einem Admin-Bereich machen kann.
Die Einstellungen soll nur ich machen können, ich will für die drei oder vier Sachen keine externe Datenbank nutzen und wenn ich alles in eine txt-Datei ablege, dann könnte jemand meine Einstellungen ändern.

Jetzt meine frage:

Hat Java schon soetwas wie eine interne Datenbank oder
gibt es da eine einfach und schnelle Lösung? Ohne das jemand an die Einstellungen ran kommt.

LG
Ingerten

 

[Kevin94]

Wenn du es sicher machen willst, brauchst du ein Passwort, dass du dann jedes mal eingeben musst, alles andere lässt sich spätestens durch decompilen knacken.

Fertige Lösungen zum Speichern (so wie Cookies im Browser) hat Java nicht, aber mit der Properties-Klasse ist es nicht mehr viel Aufwand, du musst nur festlegen wohin gespeichert werden soll. Da Properies in einen Stream schreibt bzw. draus liest, kannst du die Daten einfach über einen CipherOutput/InputStream laufen lassen, der das ganze dann ver-/entschlüsselt.
Ein Beispiel, wie man Die CipherStreams zur symmetrischen Verschlüsselung nutzen kann findest du da: File Encryption and Decryption using AES Symmetric key Cryptographic algorithm | Academic Stuffs

 

[Tobse]

Da Properies in einen Stream schreibt bzw. draus liest, kannst du die Daten einfach über einen CipherOutput/InputStream laufen lassen, der das ganze dann ver-/entschlüsselt.
Ein Beispiel, wie man Die CipherStreams zur symmetrischen Verschlüsselung nutzen kann findest du da: File Encryption and Decryption using AES Symmetric key Cryptographic algorithm | Academic Stuffs

Ach du meine Güte:

// Aus dem Link von Kevin94
Cipher encrypt =Cipher.getInstance("AES/ECB/PKCS5Padding", "SunJCE");

2 Kapitalfehler!
1. ECB Mode (siehe Block cipher mode of operation - Wikipedia, the free encyclopedia).
2. PKCS5 Padding. Das ist veraltet und unterstützt Known-Plaintext-Attacken. Aktueller Stand: PKCS7 o.ä.

Ausserdem ist druch das bloße Verscchlüsseln noch lange nicht gesagt, dass die Daten seit demn Letzten Zugriff der Software nicht Verändert wurden (Thema digitales Signieren).

Um sichere Verschlüsselung bereitstellen zu können, muss man sie komplett verstehen. Hat man sie nicht verstanden macht man sehr, sehr leicht Fehler. Und schon der kleinste Fehler macht ein gesamtes System komplett brüchig.

@TO: Du kannst zum Speichern, wie Kevin94 schon sagte, der EInfachheit halber Properties nutzen; das sind im Grunde aber Textdateien.
Wenn du eine Datenbank willst kannst du etwas wie SQLite benutzen.

 

[Kevin94]

Ich glaube nicht dass es dem TO darum ging, eine Verschlüsselung aufzubauen, die TopSecret Bedingungen erfüllt. Es kam mir nur etwas dämlich vor, ROT13 oder Cäsar zu empfehlen, was wohl genauso den Zweck erfüllen würde.
Und wie hilft einem Signieren, wenn das Zertifikat, dass man dazu braucht im Programm enthalten ist, dann steht immernoch nur ein normales Passwort zwischen Angreifer und Daten. Da kann man auch ne viel einfachere Verschlüsselung verwenden.
Wenn man es ganz sicher machen will, speichert man es auf nem eigenen Webserver und implementiert eine Zwei-Wege-Authtifizierung.
Aber ich denke diese Vorschläge dürften alle mit Kanonen auf Spatzen geschossen sein. Wenn es sich um ein privates Projekt handelt (wovon ich im Moment ausgehe), dürften es schon ausreichen, wenn du die Daten unverschlüsselt in einem versteckten Ordner (z.B. in AppData oder user.home) speicherst.
Bei Kryptographie muss man sich immer die Frage stellen, wie viel Zeit ein Angreifer zu investieren bereit sein würde, denn darauf läuft es immer hinaus, mit der BruteForce Methode lässt sich jede Verschlüsselung knacken, es ist nur eine Frage der Rechenpower. Eine Unsymetrische Verschlüsselung (RSA) wird im Moment noch als unknackbar betrachtet, weil es keinen Algorithmus gibt, der das zugrunde liegende mathematische Problem in kurzer Zeit lösen kann (selbst mit viel Rechenpower liegt die Schätzung im Moment noch bei Jahren). Selbiges gilt auch für Code-Obfuscation und ReverseEngineering: Mann kann es den Angreifern nur schwerer machen, und niemals unmöglich.
Ich hatte bei privaten Projekten schon Diskussionen mit anderen über das Thema verschlüsselte Speicherung von lokale Daten und am Ende haben Sie eingesehen, dass das Windows-Passwort eigentlich Absicherung genug ist, da die Daten bei weitem nicht so sensibel sind, dass sich irgendjemand diese Mühe machen würde.

 

[Tobse]

@Kevin94:
Ich sehe auch, dass der TO mit sicherheit keine Angst haben muss, dass ihm die Daten für sein Übungsprojekt gestohlen werden. (Ich habe ja auch zu Properties oder SQLite geraten, da ist der Aufwand um an die Daten zu gelangen minimal).

Aber: Mir geht es ums Prinzip. Wenn wir hier etwas vorstellen dann muss es fundiert sein. Ich sehe es kommen dass ein Anfänger hier diesen Code in sein erstes größeres Android-Projekt copy&pasted und seine User dann dadurch anfällig macht. Schlussletztendlich wird der Entwickler welcher sich auf diesen Code verlassen hat vielleicht sogar Rechtlich belangt.

mit der BruteForce Methode lässt sich jede Verschlüsselung knacken, es ist nur eine Frage der Rechenpower.

Theoretisch richtig. Es ist aber selbst mit einer Milliarde GPUs schon rein Zeitlich nicht möglich, das zu bewerkstelligen (500 Milliarden Jahre und mehr für einen 256-Bit Schlüssel). Mal davon abgesehen müsste man die gesamte abgestrahlte Energie der Sonne über 30 Jahre hinweg sammeln um allein genügend Energie zu haben um von 0 bis 2^256 zu zählen (256-bit Schlüssel). (Quelle: Time and energy required to brute-force a AES-256 encryption key. : theydidthemath)

Eine Unsymetrische Verschlüsselung (RSA) wird im Moment noch als unknackbar betrachtet, weil es keinen Algorithmus gibt, der das zugrunde liegende mathematische Problem in kurzer Zeit lösen kann (selbst mit viel Rechenpower liegt die Schätzung im Moment noch bei Jahren).

Bei Jahren? Es hat Jahre gebraucht um eine 768-bit Zahl in ihre Primfaktoren zu zerlegen (RSA Factoring Challenge - Wikipedia, the free encyclopedia). Ein 1024-bit Schlüssel ist um 2^256 mal länger (wir erinnern uns: allein das Zählen auf 2^256 dauert länger als es das Universum gibt). Ohne Quantencomputer kannst du das Zeitlich vergessen. Und selbst mit: Der Energieaufwand bleibt derselbe (Thermophysik).

Bei Kryptographie muss man sich immer die Frage stellen, wie viel Zeit ein Angreifer zu investieren bereit sein würde

Nein, muss man sich nicht. Denn das ist eine Abschätzung. Und schätzen war in der Kryptographie schon immer tödlich wenn es eine Alternative gab, mit der man auf nummer Sicher hätte gehen können (Beispiel DES und Triple-DES).

In der Kryptographie meint man mit der Stärke einer Verschlüsselung nicht, wie gut sie gemacht ist sondern wie Einfach/Zeitaufwendig das knacken des Blockciphers ist. Aber ob eine Verschlüsselung auch sicher ist hängt von den Verwendeten Umständen ab:
- Zufällligkeit der Schlüssel (in der Kryptograhpie auch Entropie)
- Das Verwendete Padding (wie gesagt, PKCS5 ist da unzureichend)
- Der Verkettungsmodus für Blockverschlüsselung (ECB ist das schlimmste von allem)

Und es gab in der Geschichte Beispiele genug: Ein Schlechtes Padding oder vorhersehbare Zufallszahlen können (ein paar MB an Verschlüsselten Daten vorausgesetzt) die Zeit zum knacken einer Verschlüsslung von Milliarden von Jahren auf ein paar Stunden oder Tage reduzieren. Und das ist das Problem.

 

[Kevin94]

@TO Was mir noch eingefallen ist: Du kannst die Datei in nen TrueCrypt-Ordner legen, minimaler Aufwand und hundertprozentige Sicherheit.

@Tobse Das es hier nur ums Prinzip gehen kann und nicht mehr um die Frage des TOs hätte mir klar sein müssen, danke für die Richtigstellung. Wenn du den Anmerkung zum Link nochmal genau liest, wirst du festellen, dass es als Beispiel für die Verwendung von CipherStreams gedacht ist, und nicht als Beispiel für die Auswahl des am besten geeignesten Algotihmus. Auch wenn ich in meinem Unwissen, wie ich zugeben muss, nicht darauf geachtet habe, wie sicher der verwendete ist.

 

[Tobse]

@Tobse Das es hier nur ums Prinzip gehen kann und nicht mehr um die Frage des TOs hätte mir klar sein müssen, danke für die Richtigstellung. Wenn du den Anmerkung zum Link nochmal genau liest, wirst du festellen, dass es als Beispiel für die Verwendung von CipherStreams gedacht ist, und nicht als Beispiel für die Auswahl des am besten geeignesten Algotihmus. Auch wenn ich in meinem Unwissen, wie ich zugeben muss, nicht darauf geachtet habe, wie sicher der verwendete ist.

@Kevin94 und @TO:

Wenn die Daten wirklich sicher sein sollen, ist folgendes nötig:

Aus einem Passwort muss ein Schlüssel abgeleitet werden, vorzugsweise mit PBKDF2. Mit diesem Schlüssel kannst man den Code, welcher unter dem Link zu finden ist, den Kevin94 gepostet hat, fast 1-zu-1 übernehmen mit zwei kleinen Änderungen:

1. Aus

AES/ECB/PKCS5Paddding

wird

AES/CBC/PKCS7Padding

2. Der IV für den CBC-Mode muss mit abgespeichert und beim entschlüsseln wieder angegeben werden.

Damit wären die Daten - vorausgesetzt niemand errät das Passwort (!nicht den Schlüssel) - nur für die Menschen mit Passwort zugänglich. Jeder Andere braucht ne eigene Sonne und Mehr Rechenkraft als der Planet zu bieten hat.

Die Einfache Variante wäre wirklich auf einen TrueCrypt-Ordner zu setzen (was ich für eine ziemlich simple sowie gute Idee halte, denn TrueCrypt macht beim Verschlüsseln nichts falsch).

 

[Anti-Banane]

@Tobse
ich hab mir jetzt eure diskusion erlich gesagt nicht durchgelesen ... und auch nicht mal wirklich nur grob überflogen ...

ABER : ich musste mir erstmal den unterschied zwischen pkcs5 und pkcs7 googlen um zu wissen auf was du anspielst (wäre übrigens sehr freundlich gewesen wenn du dies gleich mal mit erklärt hättest) ... jedoch hat mir google KEINEN beleg für deine behauptung geliefert

um es erstmal auch für andere klar zu machen

PKCS#5 basiert auf 64bit block-größe und war ursprünglich für DES konzipiert
das padding bewegt sich also immer nur zwischen 0x01 und 0x08
da AES eine blockgröße von 128bit haben wir also im "schlimmsten fall" folgendes padding : | 0xXX 0x07 0x07 0x07 0x07 0x07 0x07 0x07 | 0x08 0x08 0x08 0x08 0x08 0x08 0x08 0x08 |

PKCS#7 ist da in sofern etwas "dynamischer" als das nicht mit einer festenblockgröße definiert wurde sondern sich dynamisch auf die block-größe des algorithmus anpasst ... also von 0x01 bis block-größe (laut RFC 2315 10.3 Note 2 bis max 255 byte = 2040 bit ... also auch für RSA2048 noch geeignet)
in unserem beispiel hätte wir dann also | 0xXX 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F | 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F |


ich habe leider keine genaue auskunft darüber gefunden welches padding von "den großen" wie libSSL oder so genutzt wird ... und auch wie gesagt nicht eine aussage darüber das #7 im vergleich zu #5 sicherer wäre ... oder um den worten von Tobse zu sprechen : auch keinen der #5 grundsätzlich als unsicher aufklärt ... werde mir aber trotzdem für meine eigenen codes jetzt auch wohl eher #7 angewöhnen


bezüglich des block-modes : ECB sollte man wirklich nicht nutzen ... CBC ist da schon deutlich besser ... stimmt schon ... aber ich glaube "den" besten mode wird es nicht geben ... denn auch wenn die weiteren modes eine andere komplexität haben so sind dann doch wieder weniger verbreitet ... alles so ein für und wieder

 

[Tobse]

ABER : ich musste mir erstmal den unterschied zwischen pkcs5 und pkcs7 googlen um zu wissen auf was du anspielst (wäre übrigens sehr freundlich gewesen wenn du dies gleich mal mit erklärt hättest) ... jedoch hat mir google KEINEN beleg für deine behauptung geliefert

um es erstmal auch für andere klar zu machen

PKCS7 enthält zufällige Daten. PKCS5 nicht. Bei 128bit haben wir übrigens nicht 8 Zeichen sondern 16, sprich bei PKCS5:

0x?? 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F

Je nachdem welches Protokoll der TO verwendet kann es also sein, dass 16 100%ig vorhersehbare Bytes in den AES-Cipher gelangen. Bei PKCS7 wäre, selbst wenn der nicht gepaddete input 100% vorhersehbar ist, der plaintext, welcher in den Cipher geht, nicht vorhersehbar. Daher unterstützt PKCS5 schonmal known-plaintext Attacken.
Wenn man dazu dann auchnoch ECB benutzt kann man ganz schnell ein Replay einrichten o.ä und über Cryptoanalyse (genügend Quelldaten vorausgesetzt) auch sehr schnell auf den Schlüssel schließen.

bezüglich des block-modes : ECB sollte man wirklich nicht nutzen ... CBC ist da schon deutlich besser ... stimmt schon ... aber ich glaube "den" besten mode wird es nicht geben ... denn auch wenn die weiteren modes eine andere komplexität haben so sind dann doch wieder weniger verbreitet ... alles so ein für und wieder

Welcher Modus jetzt die meiste Sicherheit bietet wird sich wohl nie klären. Aber es gibt unterschiede in der Einfachheit und Gefährlichkeit der Anwendung. CTR zum Beispiel ist sehr einfach. Achtet man aber nicht pinibel darauf, dass der IV immer verschieden ist, kann die ganze Verschlüsselung den Bach runter gehen.
Eine korrekte implementierung vorausgesetzt ist es also egal, welchen Mode man verwendet solange es nicht ECB ist. Denn der hat im vergleich zu den Anderen erwiesener weise nur Nachteile.

 

[crypto]

Also um mal etwas zusammenzufassen...

An alle anfänger: Ein mal eben schnell zusammengezimmerte Krypto-implementierung / funktion / etc.
is NIX (!!!) für ein produkives system!
Privat muss jeder selber wissen, was er einsetzen will...

In der kryptographie sin aussagen wie benutz "DAS" statt "JENES" IMMER im zusammenhang zu sehen,
also nur weil manchmal eine spezielle vorgehensweise empfehlenswert ist, heißt das nicht, dass sies immer ist!

Also nix copy-pasten wenn mans nich verstanden hat...

 

[Ingerten]

Hallo Männers, das WE ist vorbei und da bin ich wieder.

Ich habe eure Diskussionen mit Interesse verfolgt und wieder was gelernt, ich denke mal das ich mein vorhaben mit einer DB lösen werde, so wie es der @Tobse vorgeschlagen hat, da kenne ich mich noch am besten aus.
Aber ich werde mir vorher mal diese "Properties-Klasse" anschauen, die der @Kevin94 vorgeschlagen hat, wenn das mein Verstand
zulässt, werde ich es damit realisieren.

Eins will ich noch los werden.
ich finde euer Forum nicht schlecht, es dauert nicht lange bis jemand antwortet und fachlich gesehen, wird man hier gut beraten,
ich habe schon viel im Forum gelesen, was mir weiter geholfen hat.

Aber,
manchmal scheu ich mich davor was in einem Forum zu Posten, weil es sehr oft so ist,
das es zu streitereien kommt oder das die Sache sehr schnell aus dem Auge verloren wird.

LG

 

[Tobse]

ich finde euer Forum nicht schlecht, es dauert nicht lange bis jemand antwortet und fachlich gesehen, wird man hier gut beraten,
ich habe schon viel im Forum gelesen, was mir weiter geholfen hat.

Freut mich zu hören

Aber,
manchmal scheu ich mich davor was in einem Forum zu Posten, weil es sehr oft so ist,
das es zu streitereien kommt oder das die Sache sehr schnell aus dem Auge verloren wird.

LG

Wenn sich die Antwortenden untereinander streiten: lass sie machen Es kursiert - und so war es auch in diesem Thread - sehr viel Fachwissen hier im Forum. Die Praxis sieht oft anders aus und da hat jeder seine eigenen Erfahrungen. Deshalb bekommen sich die Mitglieder hier gern wegen Details in die Haare, die dem TE oft nicht wichtig erscheinen und meist auch nur prinzipieller Natur sind als dem TE zu helfen. Daher: filtere die Infos raus, die für dich wichtig sind Wenn ich sage: "Krypto nur, wenn du genau weisst wie" und du es nicht weisst, brauchst du dir die Fachdiskussion dazu nicht durchlesen sofern es dich nicht sowieso interessiert

Wegen den anfeindungen gegenüber der TE's: Es gibt leider Nutzer hier welche sich öfters mal im Ton vergreiffen wenn sie versuchen, dem eher ahnungslosen TE die Fakten nahezubringen. Nimm sowas nicht persönlich - fachlich sind auch diese Beiträge selten falsch. Es gibt aber auch Regeln, an die man sich halten sollte wie z.B. erstmal Google und die Forensuche zu benutzen. Wenn dein Anliegen an eine eigene Software gebunden ist wird dir das Suchen selten weiterbringen solange du nicht genügend abstrahierst - für einen Anfänger eher schwer. Da ist es - und so war es in diesem Thread - völlig okey, nachzufragen. Aber wenn hier regelmäßig Threads eröffnet weren alá "Was ist der unterschied zwischen public und private" oder "Was ist ein Interface?" nervt es zurecht.

 

[Anti-Banane]

sry tobse ... aber deine antwort auf meine ist leider mal sowas von dermaßen falsch ... das ich das hier einfach mal grade stellen muss

1) PKCS#5 und PKCS#7 sind padding-schemata ... schreiben also vor unter welchen regeln ein input variabler länge auf einen output konstanter länger (bzw korrekterweise einem vielfachen der blocklänge) gebracht

ERGO : da durch weil es ein festes muster ist KANN es schon mal gar keine zufälligen daten enthalten

2) PKCS#5 ist nur 64bit = 8 Byte ... daher ist ein padding-wert größer 0x08 unzulässig ... und 0x08 würde auch nur dann kommen wenn ein ganzer block, also volle 64bit gepadded werden
hier muss ich jetzt erlich gesagt gestehen das ich jetzt nicht aus dem kopf weis ob bei PKCS-padding nur gepadded wird wenn nötig oder wie z.b. bei MDx oder SHAx grundsätzlich immer .. auch wenn der input bereits passende länge hat

ergo : das von dir gepostete muster " | 0xXX 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F | 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F | " kann gar kein PKCS#5 sein ... sondern ist eben, wie ich es auch korrekt erklärt habe , PKCS#7

3) mir ist durchaus bewusst das sich padding für known-plain-text-attacks nutzen lässt ... vor allem im zusammenhang mit ECB ... aber man kann AES auch im NO-PADDING verfahren laufen lassen ... so das man durchaus eine mögliche operation AES/ECB/NoPadding erhält ...
klar ist diese variante schon alleine auf grund ECB selbst sehr anfällig ... eleminiert aber den möglichen plain-angriff übers PKCS-padding

ergo : es ist erstmal egal ob PKCS#5 oder PKCS#7 ... da beide ein festes muster haben eigenen sich beide genau gleich gut für einen known-plain-text-attack ... PKCS#7 im falle von ECB sogar noch ein stück mehr da entsprechend die anzahl der bekannten blöcke im gegensatz zu PKCS#5 deutlich größer ist und man so mehr angriffsfläche hat


4) auch bei CBC hat man darauf zu achten das man die kombination Key1+IV1 nur genau ein mal nutzt um so halt einen reply-attack zu verhindern ... es spielt keine rolle ob das mit CBC, CTR oder OFB gemacht wird und hat mit dem padding auch schon mal überhaupt nichts mehr zu tun




ich fass mal die punkte 1-4 kurz : du hast einen so dermaßen absoluten bullshit geschrieben ... was mir zeigt das du von dem wo von du da gesprochen hast mal sowas von überhaupt gar keine ahnung hast ... das ich mich echt fragen muss warum ich überhaupt nachgefragt habe


das ECB ungünstig ist ... gut ... liegt auf der hand und kann man auch überall nachlesen ... das aber ein bestimmtes padding-schema einfluss auf die sicherheit eines crypto-algos haben soll ... da müssen schon ne ganze menge unglücklicher umstände zusammen kommen bis man wirklich soweit ist

 

[Tobse]

sry tobse ... aber deine antwort auf meine ist leider mal sowas von dermaßen falsch ... das ich das hier einfach mal grade stellen muss

Du hast einges, gefährliches Halbwissen. Lass mich das auch nochmal richtigstellen:

1) PKCS#5 und PKCS#7 sind padding-schemata ... schreiben also vor unter welchen regeln ein input variabler länge auf einen output konstanter länger (bzw korrekterweise einem vielfachen der blocklänge) gebracht

ERGO : da durch weil es ein festes muster ist KANN es schon mal gar keine zufälligen daten enthalten

Ich weiss, was Padding Schemata sind. AES bietet 16 byte input bröße. Mindestens ein Byte geht drauf, weil man irgendwo die länge des Plaintext markieren muss bleiben also 15 byte für den Plaintext. Ein byte hat aber einen Wertebereich von 0 bis 255, notiert werden müssen aber wie gesagt maximal 15. Da bleiben ein paar bits die man zufällig setzen kann. Und nichts spricht dagegen einen weiteren byte zu reservieren um ihn mit zufallsdaten zu füllen. Schau dir PKCS7 für Siganturen und für asymmetrische Kryptographie an, da sind zufällige bytes vorgeschrieben.

2) PKCS#5 ist nur 64bit = 8 Byte ... daher ist ein padding-wert größer 0x08 unzulässig ... und 0x08 würde auch nur dann kommen wenn ein ganzer block, also volle 64bit gepadded werden
[...]
ergo : das von dir gepostete muster " | 0xXX 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F | 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F | " kann gar kein PKCS#5 sein ... sondern ist eben, wie ich es auch korrekt erklärt habe , PKCS#7

So die Spezifikation. In der Praxis wird das aber oft so gemacht, wie ich geschrieben hatte. AES braucht 16 bytes. Man kann es nicht mit 9 betreiben. Und wenn man den Rest mit 0en auffüllt, wie soll der entschlüsselnde wissen ob die nicht teil des Plaintext waren? Sprich: wenn du java sagst AES/.../PKCS5Padding dann muss es ja irgendwas machen um auf die 16 bytes zu kommen. Und das ist eben genau das, was ich schrieb.

hier muss ich jetzt erlich gesagt gestehen das ich jetzt nicht aus dem kopf weis ob bei PKCS-padding nur gepadded wird wenn nötig oder wie z.b. bei MDx oder SHAx grundsätzlich immer .. auch wenn der input bereits passende länge hat

Es ist immer mindestens ein Byte fürs paddinng sonst würden bytes des plaintext für informationen aus dem padding gehalten.

3) mir ist durchaus bewusst das sich padding für known-plain-text-attacks nutzen lässt ... vor allem im zusammenhang mit ECB ... aber man kann AES auch im NO-PADDING verfahren laufen lassen ... so das man durchaus eine mögliche operation AES/ECB/NoPadding erhält ...
klar ist diese variante schon alleine auf grund ECB selbst sehr anfällig ... eleminiert aber den möglichen plain-angriff übers PKCS-padding

Ich sagte ja auch: Wenn der Plaintext 16 vorhersehbare bytes enthält (und bei schlampig oder nicht dafür ausgeleten Protokollen kommt das schonmal vor) dann ist ein AES/ECB/NoPadding so ziemlich das schlechteste, was du machen kannst. Padding muss zum einsatz kommen (alleine der fehlenden Garantie wegen, dass der plaintext immer ein vielfaches der Blockgröße ist).

4) auch bei CBC hat man darauf zu achten das man die kombination Key1+IV1 nur genau ein mal nutzt um so halt einen reply-attack zu verhindern ... es spielt keine rolle ob das mit CBC, CTR oder OFB gemacht wird und hat mit dem padding auch schon mal überhaupt nichts mehr zu tun

Du weisst, wie CTR funktioniert? Schau das mal nach. Klar, bei gleichem Key und IV kann ich imme rein reply machen. Bei gleichem Key und IV mit CTR kann ich das XOR von immer zwei plaintext-blöcken erhalten. Das ist suboptimal.
Und nochwas: Bei einem nicht-randomisierten Padding kann ich im CTR modus mehr von dem output des AES-Ciphers herausfinden als mit einem randomisierten. Hilft zwar nur mit sehr vielen Daten etwas aber gut ist es deswegen trotzdem nicht.

das aber ein bestimmtes padding-schema einfluss auf die sicherheit eines crypto-algos haben soll ... da müssen schon ne ganze menge unglücklicher umstände zusammen kommen bis man wirklich soweit ist

Da stimme ich dir zu. Mir geht es hier wie bereits gesagt aber nicht um die Praxis sondern ums Prinzip. Und wenn eine Schwachstelle, sei sie auch noch so unbedeutend und klein, korrigiert werden kann sollte das passieren. Denn wenn von solchen Schwachstellen mal 10 oder 20 zusammenkommen dann kann das ausreichen, um als "ne ganze menge unglücklicher umstände" durchzugehen.

du hast einen so dermaßen absoluten bullshit geschrieben ... was mir zeigt das du von dem wo von du da gesprochen hast mal sowas von überhaupt gar keine ahnung hast ... das ich mich echt fragen muss warum ich überhaupt nachgefragt habe

Lass mich mal die Forenregeln zusammenfassen: Wer sich derart äußert und hofft, ernst genommen zu werden, sollte in Zukunft die Fresse halten. Du hast weniger Ahnung von der Thematik als ich, was alleine deine Aussage "Padding kann garnicht randomisiert sein" belegt. Tu bitte in Zukunft nicht so, als hättest du die Weisheit mit Löffeln gefressen.

 

[OnDemand]

Zum speichern von Daten hat mir schon oft die Serialisierung weitergeholfen, wenn eine Datenbank to much war.

 

[Ingerten]

Ok, wie funktioniert das genau @NicoDeluxe und gibt es da ein paar Sachen, wo man drauf achten muss?

 

[OnDemand]

Ist ganz Easy Interface Serilizable implementieren und dann hier lesen:

Javabeginners - Daten serialisieren

Bei Fragen kannste gerne fragen

PS: Was für Daten möchtest eigentlich speichern? Vielleicht reicht auch schon eine Datei (csv)?

 

[Ingerten]

Hört sich garnicht so schlecht an, ich werde mich mal in die Thematik einarbeiten und melde mich wieder, wenn ich fragen habe.

PS: Ich will eigentlich nur ein paar Einstellungen für mein Programm speichern, sowas wie ein Datei-Pfad und so ein paar kleine sachen.
ich will aber nicht, das einer hergeht und das ändern kann, dafür habe ich ein kleinen Admin-Bereich gemacht, damit ich es nicht immer im QuellCode ändern muss.

besten dank @NicoDeluxe :toll:

 

[dzim]

Um den armen TO noch weiter zu verwirren :-D
Du kannst deine Modell-Klassen auch nach XML oder JSON serialisieren

public class Model {

  private String myValue;

  public String getMyValue() {
    return myValue;
  }

  public void setMyValue(String value) {
    this.myValue = value;
  }
}

JAXB: JAXB - Tutorial
Simple (XML Serialization): Simple 2.7.1

Beide serialisieren deine Klasse nach XML, beide verwenden aber zusätzliche Annotationen (die nicht zueinander Kompatibel sind, also eine JAXB-annotierte Klasse kann man leider nicht mit Simple serialisieren, oder umgekehrt):

@XmlRootElement
@XmlElement(name="model")
public class Model {

  @XmlAttribute(name="my-value")
  private String myValue;

  public String getMyValue() {
    return myValue;
  }

  public void setMyValue(String value) {
    this.myValue = value;
  }
}

Achtung: Ich hab das aus dem Gedächtnis geschrieben... Und das ist nicht immer das Beste! ;-)

Einfacher geht es meist mit JSON:
Jackson: Jackson JSON Processor - Home
GSon: https://code.google.com/p/google-gson/

Bei Jackson, weil ich ihn häufiger nutze, weiss ich, dass ich die Klasse im Prinzip so verwenden kann wie ganz oben angegeben. Nur wen du spezielle Checks benötigst, sind ebenfalls Annotationen sinnvoll.

Vorteil JSON: Schnell, einfach zu verwenden und extrem verbreitet - dank dem Internet und (*würg*) JavaScript. Also eine leichtgewichtige und lesbare Serialisierung.

Vorteil XML: Richtig annotiert und noch idealerweise mit einem Schema versehen kann man XML-Daten hervorragend valide halten. Heisst: Du kannst im Vorfeld (bevor du die Daten speicherst oder lädst) sicherstellen, dass alle Daten enthalten sind, die du im weiteren Verlauf benötigst.
Nachteil XML: Schwerer zu lesen (da kann man diskutieren) und wenn man alles auf Nummer sicher haben möchte, ist höherer Aufwand von Nöten.

 

[Ingerten]

Also, du hast es geschaft @dzim, die Verwirrung ist da.

Als erstes mal zum Thema Sicherheit:
Das Tool, was ich geschrieben habe, ist für eine Gruppe von Menschen, wo ich froh sein kann, wenn 80% den Rechner an bekommen und die richtige Anwendung starten können.
Dann habe ich sicher noch 19%, die mit Java nichts anfangen können und dann wär vielleicht noch 1% die was drauf haben,
aber dieses eine Prozent, na ja....

Ich glaube, wenn ich einfach eine "txt" anlege, können die wenigsten was damit anfangen.
Aber mir geht es eigentlich in erster Linie um mich, ich will auch was dazu lernen, z.b. für die nächsten Projekte.

Ihr glaubt garnicht, was ich so den ganzen Tag erlebe, in sachen Computern.
z.b.: eine Kundin hat letzten Monat bei uns angerufen und meinte das unser Programm nicht mehr gehen würde, sie kann keine Daten mehr speichern. Die Fehlermeldung war sinngemäß "der Datei-Pfad ist zu lang".
Jetzt habe ich ihr versucht zu erklären das ein Datei-Pfad nur 255 Zeichen haben darf, das wollte die Frau einfach nicht verstehen und da habe ich dann einfach gesagt, das es nicht an unserer Software liegt, sondern an Microsoft, die geben einen diese 255 Zeichen vor und die gute Frau meinte dann zu mir, das sie jetzt gleich mal bei Microsoft anruft, sie hätte keine lust jetzt jeden Datei-Pfad zu ändern. ;(

 

[Ingerten]

So, ich denke mal, ich bin mit meinem Projekt so gut wie fertig, es sind nurnoch ein paar kleine Sachen

und aus diesem Grund möchte ich mich erstmal für eure Hilfe bedanken, ich glaube ohne die Hilfe aus dem Forum
wäre ich nie fertig geworden oder hätte zumindest ein ganzes Stück mehr Zeit gebraucht.

Also dann bis zum nächsten Projekt und Danke nochmal
:toll: