Viele Verschlüsselungen sind unter den Randbedingungen entstanden: "Muss auch auf schwacher Hardware laufen." Ist das im Jahre 2016 noch ein "Zeitgemäßes" kriterium? Ich meine, aktuelle Mobiltelefone haben 4 bis 8 Kerne mit mehr als 2 GHz Takt und mehr als 2GB RAM, über Desktop PC und Server Hardware braucht man gar nicht reden. Selbst ein 10 Jahre alter PC hat immernoch mehr als genug Rechenleistung. Im embedded Bereich gibt es immer mehr ARM-Controller, die auch eine recht hohe Rechenleistung und 32bit-Cores haben. Ebenso gibt es mittlerweile Prozessoren mit FPGA Einheit z.B. Intel + Altera. Sagen wir mal, man würde jetzt eine neue Verschlüsselung entwickeln. Bis das abgeschlossen, überprüft, durch Wettbewerbe und Gremien gewandert ist, sind gut und gerne mind. 5 Jahre vergangen, bevor das überhaupt mal in die freie Wildbahn gelangt. Würdet Ihr in der heutigen Zeit noch das Kriterium stellen, das es mit "8bit CPU/wenig RAM" usw. laufen muss? Wenn ja, warum? In ein seit 10 Jahren bestehendes Produkt wird man wohl kaum eine neue Verschlüsselung reindrücken. Da würde man wohl eher ein Redesign mit einem entsprechenden Prozessor/µC machen. Nein, diese Frage hat keinen tieferen Sinn, mich interessiert nur eure Meinung :) Grüße
Die Frage ist doch: Warum sollte man auf eine neue Verschlüsselung setzen, wenn die bestehenden (AES bspw.) als sicher gelten? Gerade in dem Bereich wäre es ein großes Risiko, auf eine neue, eventuell mathematisch noch nicht gut genug erforschte Methode zu setzen. Von der neu zu prüfenden Fehlerfreiheit des Codes mal ganz abgesehen. Es spricht wenig für neue Algorithmen, aber sehr viel dagegen.
Chris D. schrieb: > Warum sollte man auf eine neue Verschlüsselung setzen, wenn die > bestehenden (AES bspw.) als sicher gelten? Ich denke das es falsch ist, sich auf etwas zu verlassen was heute sicher ist und auch in den letzten 20 Jahren sicher war, aber das kann morgen oder nächstes Jahr schon ganz anders aussehen. (übertrieben dargestellt) Die Enigma galt auch mal als sicher, wie vieles andere auch, was mittlerweile in Sekunden/Minuten/Stunden gebrochen werden kann. Chris D. schrieb: > Gerade in dem Bereich wäre es ein großes Risiko, auf eine neue, > eventuell mathematisch noch nicht gut genug erforschte Methode zu > setzen. > > Von der neu zu prüfenden Fehlerfreiheit des Codes mal ganz abgesehen. Richtig, aber wenn man nichts tut, bis AES vielleicht mal nicht mehr als sicher gilt (plastisches Beispiel!), dann sitzen wir alle für mind. 5 weiter Jahre auf einer gebrochenen Verschlüsselung, bis eine neue da ist. Kontinuierliche Forschung wäre, meiner Meinung nach, das einzig richtige, gerade weil es so lange dauert bis die Spezifikationen und der Code überprüft wurden. Ansonsten stimme ich dir voll und ganz zu. Es ist nicht ohne Risiko, auf etwas neues zu setzen. Sich aber ausschließlich auf das alte zu verlassen ist nicht weniger risikobehaftet.
Kaj G. schrieb: > Chris D. schrieb: >> Warum sollte man auf eine neue Verschlüsselung setzen, wenn die >> bestehenden (AES bspw.) als sicher gelten? > Ich denke das es falsch ist, sich auf etwas zu verlassen was heute > sicher ist und auch in den letzten 20 Jahren sicher war, aber das kann > morgen oder nächstes Jahr schon ganz anders aussehen. (übertrieben > dargestellt) > Die Enigma galt auch mal als sicher, wie vieles andere auch, was > mittlerweile in Sekunden/Minuten/Stunden gebrochen werden kann. Es gibt heutzutage aber nicht nur eine erprobte Verschlüsselungsart. Du kannst schon heute aus vielen verschiedenen wählen (bspw. bei ssh-Verbindungen). Ein Umstieg auf eine andere wäre also nur so etwas wie ein "Mausklick". > Richtig, aber wenn man nichts tut, bis AES vielleicht mal nicht mehr als > sicher gilt (plastisches Beispiel!), dann sitzen wir alle für mind. 5 > weiter Jahre auf einer gebrochenen Verschlüsselung, bis eine neue da > ist. Siehe oben. Es gibt schon heute sehr viele praktisch verwendete Verschlüsselungen, die auf ganz verschiedenen mathematischen verfahren beruhen. Ein Ersatz wäre also innerhalb weniger Augenblicke verfügbar. > Kontinuierliche Forschung wäre, meiner Meinung nach, das einzig > richtige, gerade weil es so lange dauert bis die Spezifikationen und der > Code überprüft wurden. Das wird ja auch getan. Die Forschung geht kontinuierlich weiter. Aber Dir ging es ja darum, die auch praktisch einzusetzen. Und da besteht eben aktuell einfach kein Bedarf. Man hätte nur Risiken für keinen Gewinn. Warum sollte man sich das antun? > Sich aber ausschließlich auf das alte zu verlassen ist > nicht weniger risikobehaftet. Wird ja auch nicht gemacht. Getestete Alternativen stehen schon bereit und könnten sofort eingesetzt werden.
Kaj G. schrieb: > Ich denke das es falsch ist, sich auf etwas zu verlassen was heute > sicher ist und auch in den letzten 20 Jahren sicher war, aber das kann > morgen oder nächstes Jahr schon ganz anders aussehen. Oder umgekehrt: Ich denke, dass es falsch ist, sich in dieser Frage auf etwas zu verlassen, bei dem der Zahn der Zeit noch wenig Gelegenheit hatte, daran zu knabbern. Denn die Wahrscheinlichkeit, dass man in einem Verfahren Lücken findet, sinkt mit der Zeit, die Leute damit haben, sich damit zu beschäftigen. Absolute Gewissheit hat man keine, wenn man auf dem Werk anderer Leute aufsetzt. Aufgrund der Gewohnheit, in Sicherheitsfragen auch mal den Bock zum Gärtner zu machen (Interessenkonflikt in Institutionen wie NSI/NIST/BSI) war man bei sowohl bei DES und AES lange Zeit recht unsicher, was man davon halten sollte. Eine Skepsis, die sich bei anderer Gelegenheit als nützlich erwies. Wenn man andererseits ein selbst definiertes Verfahren verwendet, dann besteht eine recht hohe Wahrscheinlichkeit, dass die Sicherheit wesentlich davon bestimmt wird, wie hoch das Interesse anderer Leute am Cracken ist.
Chris D. schrieb: > Wird ja auch nicht gemacht. Getestete Alternativen stehen schon bereit > und könnten sofort eingesetzt werden. Dem Prinzip nach ja. Aber der praktische Ersatz in realer Verwendung würde ziemlich lange dauern oder unangenehme Nebenwirkungen haben. So enthalten Prozessoren mittlerweile nicht selten Cryptobefehle, die sich bei Verschlüsselung von Datenträgern als recht nützlich erweisen (Android: ab 64-Bit ARM, auch wenn nur mit 32-Bit OS genutzt). Ebenfalls ist das bei Interoperabilität ein Problem. Wer öfter mal VPNs zu anderen Firmen aufbaut, der merkt beispielsweise, dass man oft noch das veraltete SHA1 verwenden muss. Etwa weil auf einer Seite das verwendete Equipment nicht auf der Höhe der Zeit ist oder es beide zwar theoretisch können, aber nicht miteinander. Ganz zu schweigen von den vielen Chipkarten nebst Terminals. Einem 8051 mit AES Engine bringst du keine neuen Tricks bei.
:
Bearbeitet durch User
Chris D. schrieb: > Aber Dir ging es ja darum, die auch praktisch einzusetzen. In erster Linie geht es mir um das Gedankenspiel: Wenn man etwas neues entwickeln wollen würde (warum ist ja letzlich egal *[1]), würde man dann immernoch die selben Rahmenbedinungen wie vor 20 Jahren stellen? Oder würde man heute z.B. auf die kompatibilität zu 8 Bit Prozessoren verzichten, einfach um andere mathematische Konstrukte verwenden zu können (die auf einem 8 bitter aber nicht schnell genug wären bzw. waren)? Chris D. ich stimme dir ja grundsätzlich zu, aber mir geht es einfach nur um dieses Gedankenspiel: Was wäre wenn... :-/ Das es viele Alternativen gibt weiß ich (z.B. Serpent, Twofish, usw.), aber es gibt ja auch Gründe, warum sich diese Alternativen eben nicht so durchgesetzt haben wie z.B. AES. Und das ist teilweise nicht, weil sie "schlecht" sind, sondern weil die ein oder andere Verschlüsselung eben nicht die Rahmenbedinungen von vor gefühlten 20 Jahren erfüllt hat, wie die unterstützung von "schwacher" Hardware. -------------------------------------- [1] Es besteht an so vielen Dingen kein Bedarf, und trotzdem wird jeden Tag sinnloses Zeug entwickelt, das keiner braucht. Es gibt auch mehr als genug Autos, und trotzdem werden neue Entwickelt, ob wohl es ja gar nicht not tut.
Im IT-Bereich ist man eigentlich zu der Erkenntnis gelangt, daß Sicherheit kein Zustand ist, den ich einmal erreichen kann und dann bleibt das so, sondern daß Sicherheit ein kontinuierlicher Prozess ist. Die Krypto-Forschung macht ständig Fortschritte, die Hardware zum Entschlüsseln wird besser (z.B. Grafikkarten, FPGAs, ASICs,...), es gibt neue Angebote zum Knacken (Botnetze, in Cloud-Angeboten lassen sich sehr viele CPUs parallel einfach für x EUR pro CPU-Stunde mieten, etc.). Und am Horizont lauern die Quantencomputer. Das heißt Du kannst ein Produkt oder Protokoll entwickeln, welches nach dem heutigen Stand der Technik sicher ist. Das kann sich aber morgen wieder geändert haben. Daher sollte ein Produkt immer Firmware-Updates ermöglichen. Und es sollte ein Prozess und Infrastruktur von Anfang an eingebaut sein, die ein schnelles Ausrollen von Sicherheitsupdates an alle Geräte im Feld über die gesamte tatsächliche(!) Lebensdauer erlaubt. Also so ziemlich das Gegenteil von dem, was bei billigen Routern, Android, etc. praktiziert wird. Wenn es um ein Protokoll geht, sollte das so gestaltet sein, daß man es über die Jahre Stück für Stück mit neuen Krypto-Algorithmen erweitern kann und dennoch die Kompatibilität mit Altgeräten erhalten bleibt. Das ist gar nicht so einfach zu designen. Recht gut finde ich das z.B. bei IPSec gemacht.
Gerd E. schrieb: > Das heißt Du kannst ein Produkt oder Protokoll entwickeln, welches nach > dem heutigen Stand der Technik sicher ist. Das kann sich aber morgen > wieder geändert haben. Weshalb man bei auf längere Sicht gebrannten Algorithmen auch darauf achten sollte, inwieweit sie mit Quantencomputern crackbar sind. Da sind wohl nicht alle gleich gewickelt. > Daher sollte ein Produkt immer Firmware-Updates ermöglichen. Wenn da entsprechende Hardware verbaut ist, dann ist schnell Sackgasse. > ein schnelles Ausrollen von Sicherheitsupdates an alle Geräte im Feld > über die gesamte tatsächliche(!) Lebensdauer erlaubt. Also so ziemlich > das Gegenteil von dem, was bei billigen Routern, Android, etc. > praktiziert wird. Je einfacher ein Sicherheitsupdate aus der Ferne ist, desto einfacher ist es auch anderen, diesen durchzuführen. Methode FBI/Apple: Nicht das Verfahren cracken, sondern die Firmware ersetzen. > Recht gut finde ich das z.B. bei IPSec gemacht. Die Unterscheidung von IKEv1 und IKEv2 scheint eher heuristisch zu funktionieren, wie ich einem Kommentar einer Doku entnehmen konnte. Ciscos ASA wiederum scheint SHA2 nur in Verbindung mit IKEv2 zu mögen und das wiederum wollte partout nicht mit Palo Altos Verständnis davon harmonieren. Das Ende vom Lied war IKEv1/SHA1.
:
Bearbeitet durch User
Ich bin hier leider nur Laie was Verschlüsselungstechniken angeht. Aber von welchen "veralteten" Algorithmen redest du, welche Rücksicht auf alte Hardware nehmen? Außerdem ist doch eine Hashfunktion wie SHA1 etc. was völlig anderes als ein Verschlüsselungsystem wie AES, oder täusche ich mich da?
Matthias K. schrieb: > Außerdem ist doch eine Hashfunktion wie SHA1 etc. was völlig anderes als > ein Verschlüsselungsystem wie AES, oder täusche ich mich da? SHA1 ist keine Verschlüsselung, aber das grundlegende Problem ist gleich. Ist ein bestimmtes Verfahren als nicht mehr sicher erkannt, dann muss es ersetzt werden. Egal ob es sich um das Verfahren zur Verschlüsselung oder um die verwendete Hashfunktion handelt. Bei Protokollen wie IPSEC oder SSL/TLS hat man ohnehin beides drin.
:
Bearbeitet durch User
A. K. schrieb: >> Daher sollte ein Produkt immer Firmware-Updates ermöglichen. > > Wenn da entsprechende Hardware verbaut ist, dann ist schnell Sackgasse. da fehlt wohl ein "nicht". > Je einfacher ein Sicherheitsupdate aus der Ferne ist, desto einfacher > ist es auch anderen, diesen durchzuführen. Methode FBI/Apple: Nicht das > Verfahren cracken, sondern die Firmware ersetzen. auch dagegen kannst Du ein Gerät sichern, auf verschiedenen Ebenen gegen verschiedene Angriffszenarien. Aber Du musst Dir natürlich beim Design Gedanken drüber machen. Da viele Kunden über sowas (noch) nicht nachdenken, wird da meist beim Kauf nicht explizit nachgefragt und damit ist der Anreiz für die Hersteller sowas bei der Entwicklung zu bedenken oft begrenzt. >> Recht gut finde ich das z.B. bei IPSec gemacht. > > Die Unterscheidung von IKEv1 und IKEv2 scheint eher heuristisch zu > funktionieren, wie ich einem Kommentar einer Doku entnehmen konnte. > Ciscos ASA wiederum scheint SHA2 nur in Verbindung mit IKEv2 zu mögen > und das wiederum wollte partout nicht... Ich sprach vom Protokolldesign, nicht von konkreten Implementationen. Daß bestimmte Implementationen des Protokolls das dann verbocken kommt natürlich vor. Das können aber die Hersteller fixen wenn sie wollten. Wäre dagegen das Protokoll an sich buggy, würde es sehr sehr schwer das zu fixen und gleichzeitig Kompatibel zu bleiben.
Matthias K. schrieb: > Aber von welchen "veralteten" Algorithmen redest du, welche Rücksicht > auf alte Hardware nehmen? Praktisch alle gebräuchlichen. Ich sprach aber von "schwacher" Hardware, nicht von "alter". Smartcards sind schwach an Hardware (CPU/Speicher, siehe unten, Punkt 7), aber nicht alt. Ebenso wie die AES-Anforderung: "Die Anforderung der Geschwindigkeit des Algorithmus auf diversen Plattformen...", siehe unten. Zum Beispiel sind FROG und DEAL beim AES Wettbewerb (nicht nur deswegen, aber auch) rausgeflogen, weil sie "zu langsam" waren. Sie waren also für die ein oder andere Platform "ungünstig" designed. Der AES Wettbewerb wurde am 12.09.1997 endgültig ausgeschrieben, mit folgenden Regeln:
1 | 1. AES muss ein symmetrischer Algorithmus sein, und zwar eine Blockchiffre. |
2 | |
3 | 2. AES muss 128 Bit lange Blöcke verwenden (dies wurde erst während der |
4 | Ausschreibung festgelegt, zu Beginn der Ausschreibung waren auch |
5 | Blockgrößen von 192 und 256 Bit verlangt, diese wurden nur als mögliche |
6 | Erweiterungen beibehalten) |
7 | |
8 | 3. AES muss Schlüssel von 128, 192 und 256 Bit Länge einsetzen können. |
9 | |
10 | 4. AES soll gleichermaßen leicht in Hard- und Software zu implementieren |
11 | sein. |
12 | |
13 | 5. AES soll in Hardware wie Software eine überdurchschnittliche Leistung |
14 | haben. |
15 | |
16 | 6. AES soll allen bekannten Methoden der Kryptoanalyse widerstehen können, |
17 | insbesondere Power- und Timing-Attacken. |
18 | |
19 | 7. Speziell für den Einsatz in Smartcards sollen geringe Ressourcen |
20 | erforderlich sein (kurze Codelänge, niedriger Speicherbedarf). |
21 | |
22 | 8. Der Algorithmus muss frei von patentrechtlichen Ansprüchen sein und muss |
23 | von jedermann unentgeltlich genutzt werden können. |
24 | |
25 | |
26 | Die Anforderung der Geschwindigkeit des Algorithmus auf diversen |
27 | Plattformen wurde in drei zusätzlichen Zielen unterteilt: |
28 | |
29 | - Die rechnerische Geschwindigkeit mit 128-Bit-Schlüsseln. |
30 | |
31 | - Die rechnerische Geschwindigkeit mit 192-Bit- und 256-Bit-Schlüsseln |
32 | sowie die rechnerische Geschwindigkeit verschiedener Hardware- |
33 | Implementierungen. Der Speicherverbrauch und die Grenzen von Software- |
34 | Implementierungen der Kandidaten waren weitere wichtige Aspekte. |
35 | |
36 | - Das dritte Ziel, die Algorithmus- und Implementierungscharakteristiken, |
37 | beinhalteten die Flexibilität, die Eignung für Soft- und Hardware- |
38 | Implementierungen und die Einfachheit des Algorithmus. |
39 | |
40 | Unter Flexibilität verstand man die Eigenschaften, dass AES die Schlüssel- |
41 | und Blockgröße über dem Minimum unterstützen musste und dass er in |
42 | verschiedenen Typen von Umgebungen sowie zusätzlich als Stromchiffre und |
43 | kryptologische Hashfunktion sicher und effizient zu implementieren war. |
Beendet wurde dieser Wettbewerb am 2.10.2000 mit der bekanntgabe des Siegers: der belgische Algorithmus Rijndael. Hat also gute 3,5 Jahre gedauert das ganze. Die Uni Bochum macht in Ihrem Studiengang IT-Sicherheit regelmäßig Wettbewerbe, wo z.B. AES-128 in Assembler auf einem AVR implementiert werden muss. Sowas muss der Verschlüsselungsalgorithmus aber erstmal hergeben. Natürlich kann man jeden Verschlüsselungsalgorithmus in Assembler implementieren, aber nicht unbedingt sinnigerweise auf einem AVR, so dass das ganze dann auch noch brauchbar nutzbar ist. Und da kommt jetzt eigentlich meine Frage zum tragen: Die Leistungsfähigkeit der Hardware ist in den letzen ~18 Jahren exorbitant gestiegen. Wie sinnvoll ist es heute, eine Verschlüsselung zu entwickeln, die auf "allen erdenklichen Platformen", von der SmartCard bis zum Supercomputer, läuft? Natürlich, bei AES standen die SmartCards (gibt es noch schwächere, relevante Hardware?) explizit als Anforderung dabei, aber dass muss man ja nicht ungefragt für andere Fälle übernehmen. Zum Beispiel hat sich KASUMI im UMTS-Bereich durchgesetzt, also nur für einen Bereich, statt für "alles" wie AES. Eine Spezialisierung auf einen Bereich muss der Verbreitung also kein Nachteil sein. Daraus schließe ich, das der Ausschluss eines Bereiches (SmartCards/8 Bit µC) ebefalls kein Nachteil sein müsste. Natürlich hat "eine Verschlüsselung für alles" einen Vorteil: Wird ein Problem gefunden, lässt es sich "leicht" für alle Platformen fixen. Das ist aber auch gleichzeitig der größte Nachteil: Wird ein Problem gefunden, sind gleich alle Platformen betroffen.
Kaj G. schrieb: > Zum Beispiel hat sich KASUMI im UMTS-Bereich durchgesetzt, also nur für > einen Bereich, statt für "alles" wie AES. Wikipedia klingt eher so, als wäre das verglichen mit AES ein Griff ins Klo gewesen, zumindest inklusive Protokoll gesehen: https://de.wikipedia.org/wiki/KASUMI
Kaj G. schrieb: > Und da kommt jetzt eigentlich meine Frage zum tragen: > Die Leistungsfähigkeit der Hardware ist in den letzen ~18 Jahren > exorbitant gestiegen. > Wie sinnvoll ist es heute, eine Verschlüsselung zu entwickeln, die auf > "allen erdenklichen Platformen", von der SmartCard bis zum > Supercomputer, läuft? Leistung ist nicht alles. Leistungsaufnahme (Stromverbrauch) ist das andere wichtige Kriterium. Wenn du heutzutage Geräte bauen musst, die zehn Jahre mit der selben Knopfzelle betrieben werden, dann kann man sich exorbitante CPUs in die Haare schmieren. Um mal die Verhältnisse klar zu machen, weil irgendwo Smartphones erwähnt wurden. Smartphone: Vielleicht zwei Tage, ach, sagen wir eine Woche Betrieb mit einem 2000 mAh Akku. Hingegen eine Knopfzelle CR2032: 200 mAh. Viel Spaß 200 mAh über zehn Jahre (oder sogar nur ein Jahr) zu strecken. Du kannst jetzt selber andere Batterietypen und Techniken betrachten, das waren nur Beispiele. Sicher ist, dass wir in Zukunft IoT Zeug aller Art sehen werden, das zwar jahrelange ohne Batteriewechsel funktionieren wird, dessen Sicherheit aber miserabel bis nicht existent sein wird.
:
Bearbeitet durch User
A. K. schrieb: > ... als wäre das verglichen mit AES ein Griff ins > Klo gewesen, zumindest inklusive Protokoll gesehen: Nur KASUMI: http://www.hindawi.com/journals/mpe/2014/251853/ref/ Vielleicht hätten sie doch besser AES verwenden sollen.
:
Bearbeitet durch User
IMO ist es heute sinnvoll neue asymmetrischen Kryptosysteme zu bauen: https://de.wikipedia.org/wiki/Post-Quanten-Kryptographie Neue symmetrischen Kryptosysteme eher nicht (AES256 ist gut genug!)
@Kaj G Vielen Dank für die Erklärung :) Ansonsten lese ich glaube ich einfach nur mit ...
Man sollte sich auch Gedanken drueber machen wie sicher die Daten denn sein sollen. Auch hier gilt, so sicher wie noetig, nicht so sicher wie moeglich. Was geschieht, wenn die Daten eines Temperatursensors manipuliert werden? Was geschieht, wenn der Sensor einfach fehlt, Kabel ausgesteckt, resp durchgeschnitten? Faehrt ein Prozess an die Wand, oder was ?
Kaj G. schrieb: > Immernoch "schwache" Hardware berücksichtigen? Natürlich. Denn der Leistungszuwachs der Hardware ist ÜBERKOMPENSIERT durch die gigantisch angestiegenen Datenmengen, so dass schon derselbe Algorithmus heute die angewachsene Datenmenge langsamer verschlüsselt als zu der Zeit als er erfunden wurde.
Kaj G. schrieb: > Würdet Ihr in der heutigen Zeit noch das Kriterium stellen, das es mit > "8bit CPU/wenig RAM" usw. laufen muss? Wenn ja, warum? > In ein seit 10 Jahren bestehendes Produkt wird man wohl kaum eine neue > Verschlüsselung reindrücken. Da würde man wohl eher ein Redesign mit > einem entsprechenden Prozessor/µC machen. Natürlich stellt man auch heute noch die Anforderung: "Muss auf LowPower Geräten (Batteriebetrieben/Enewrgyharvesting laufen)" Und wenn LowPower eben heisst 16bit Controller 256K RAM dann muss die Soft eben auch auf diesen laufen. Wer will schon ein Babyphone das sich ratzfatz anzapfen lässt. Oder bei Keyless entry Geräten (Autoschlüssel) ist aus Gründen automotive Kostendruck die Hardware noch schmalbrüstiger. Wer zu bequem ist effizienten Code zu schreiben hat in der Embedded Branche nichts zu suchen - meine Meinung.
Was Du verwendest hängt in der Realität üblicherweise davon ab was Deine User liefern können. Wenn die veraltete Browser verwenden bleibt Dir nichts anderes übrig als längst als nicht mehr zeitgemäß geltende Verschlüsselungsalgorithmen zu verwenden. Im Normalfall sollt's allerdings kein Thema mehr sein beispielsweise RC4 endlich sterben zu lassen!
Bitwurschtler schrieb: > Wer zu bequem ist effizienten Code zu schreiben hat in der Embedded > Branche nichts zu suchen - meine Meinung. VORSICHT! In Sachen Sicherheit hat Effizienz nur eine geringe Priorität. Leider vergessen das die meissten Programmierer - oder schlimmer bekommen sowas erst gar nicht gelehrt. "Effizenter Code" ist die Grundlage bzw. die Sicherheitslücke fast aller Seitenkanalangriffe auf SmardCards/RFID-ControllerCards. Es ist sogar bequemer, effizienten Code zu schreiben, als sicheren Code zu schreiben. Ein Beispiel: Gesetzt den Fall, du programmierst eine JavaCard so, daß sie bei dreimaliger falscher 4stelliger Pineingabe keine weiteren 4stelligen Pins mehr annimmt, sondern nur noch einen bestimmten 10stelligen, der 10x probiert werden kann. (Kennt jeder von SIM-Karten). Du prüfst intern auf der Karte die Eingabe gegen deinen gespeicherten richtige PIN. Und gibst dann nach Prüfungen ein "OK" oder ein "N(och)2" aus. Dann kommt der "Verbesserungsvorschlag": "Wenn wir doch eh jedes Bit seriell als Eingabe bekommen, können wir doch gleich in der Eingabepufferzählschleife, die die Bits entgegennimmt, schon Bit für Bit mit dem gespeicherten Pin vergleichen. Dann brauchen wir doch den Rest nicht abarbeiten.." Du glaubst, so dumm kann niemand sein? Das gabs schon :D
Andy P. schrieb: > Bitwurschtler schrieb: >> Wer zu bequem ist effizienten Code zu schreiben hat in der Embedded >> Branche nichts zu suchen - meine Meinung. > > VORSICHT! > In Sachen Sicherheit hat Effizienz nur eine geringe Priorität. Geringere aber nicht geringe Priorität. Und j,a auch in der Sicherheitstechnik ist due effizientere Implementierung die sichere. Weniger LoC -> weniger Fehler. Natürlich steht über allen die qualitätsgerechte Codierung sicherer Algorithmen und sonstigen Randbedingungen. Wenn allerdings in der Spec des Algos/Programms nicht steht das die Zeit, Leistungsaufnahme etc während der Verschlüsselung/Schlüsselprüfung konstant zu halten ist kann man dem Codierer auch keinen Vorwurf machen. > Eingabepufferzählschleife, die die Bits entgegennimmt, schon Bit für Bit > mit dem gespeicherten Pin vergleichen. Dann brauchen wir doch den Rest > nicht abarbeiten.." Was haben bitweise Operationen mit Effizienz zu tun? Das gegenteil ist der Fall. MfG,
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.