Einzelnen Beitrag anzeigen

Benutzerbild von negaH
negaH

Registriert seit: 25. Jun 2003
Ort: Thüringen
2.950 Beiträge
 
#22

Re: Verschlüsselungsverfahren, welches?

  Alt 8. Okt 2004, 21:38
@mytar:

über RC4 sollte man ne Menge im WEB finden. Aber, da RC4 offiziell auf mysteriöse Weise unerlaubt aus den RSA Labs. "entflohen" ist, also nie offiziell veröffentlicht wurde, gibt es im Grunde keine anerkannten Expertiesen über dessen Sicherheit. Allerdings, das Grundprinzip und die cleveren Tricks im RC4 dienten später als Grundlage für viele andere Streamcipher. Somit haben sich wesentliche Neuheiten im RC4 Design durchgesetzt, und das spricht für dessen Sicherheit.


Zitat:
ist "Elliptic Curves" nicht patentiert? Oder habe ich mal etwas Falsches gelesen?
Nein. Das Grundprinzip aller ECC Varianten ist nicht patentiert, aber...
Man muß unterscheiden in welchen Domains und mit welchen Zahlensystemen die ECC implementiert werden. ECC arbeitet in Galois Fields -> GF() modular. Aber die Domain selber kann GF(p) oder GF(n^m) oder GF2(n) sein. GF(p) arbeitet in Zp also modularen Ringen zu einer Primzahl. GF(m^n) arbeitet ganz anders, d.h. selbst die Addition, Subrationen sind unterschiedlich definiert. Nun, die Grundlagen der ECC sind nicht patentiert, aber sehr wohl die darauf aufsetzenden verschiedenen kryptographischen Algortihmen und auch die verschiedenen nötigen mathematischen Operationen und Algorithmen damit man in GF(n^m) sehr schnell rechnen kann. Das ist deshalb bedeutsam weil die ECC ideal für SmartCard Prozessoren, also Hardware, geeignet sind. Eben weil ECC's mit kleineren Schlüsseln auskommen bei gleicher Sicherheit im Vergleich zu RSA. Ein 1024 RSA ist so sicher wie ein 168 Bit ECC. Somit sind auch die Berechnungen in ECC, besonders in GF2(n) besonders effizient und schnell in hardware zu integrieren. Nun, auf diesem Gebiet ist heutzutage eine "Schlacht" auf Patentebene im Gange. Das liegt eben auch daran das wenn man schon die Grundlagen der ECC nicht patentieren kann, man denoch versuchen kann alle nötigen mathematischen Operationen drumherum zu patentieren.

Allerdings relativiert sich das für jeden Hobby-Kryptographen, weil dieser nur an ECC in GF(p) interessiert sein sollte. Denn nur ECC in GF(p) sind tatsächlich als sicher bewiesen. D.h. man hat bis heute noch nicht eindeutig beweisen können das ECC in anderen Domains wie GF(n^m) oder GF2(n) wirklich so sicher sind wie in GF(p). man hat also noch nich mathematisch beweisen können ob man die Eigenschaften in Punkto Sicherheit aus der Domain GF(p) nach andere Domains wie GF(n^m) übertragen kann. Wenn man dies aber noch nicht mathematisch beweisen konnte so fehtl auch der mathematische Beweis das ECC in zb. GF(n^m) so sicher ist wie in GF(p).

Zudem sind auf PCs die ECC's in GF(p) nur unwesentlich aufwändiger und ineffizienter (im Millisekundenbereich), und so gibt es eigentlich keinen Grund nicht GF(p) zu nutzen. Meine GF(p) Impelemntrierung im DEC erzeugt zB. 192Bit ECC GF(p)Schlüssel in maximal 300ms und Signaturen in 2ms auf einem P4 1.5 GHz. D.h. mit ca. durchschnittlich 5 Millisekunden pro kryptographischer Operation ist man bei weitem schneller als bei anderen Verfahren wie RSA usw. Es besteht also kein Grund ECC GF(p) nicht zu benutzen. Einzigstes Augenmerk ist auf verschiedene Anstrengungen zu richten ECC durch die Hintertür zu patentieren bzw. zu blockieren. Man versucht also irgendwelche speziellen Algorithmen zu patentieren und über diese "rückwirkend" grundsätzliche unpatentierte ECC Eigenschaften zu patentieren.

Gruß Hagen
  Mit Zitat antworten Zitat