Javascript: RSA + Blowfish (advanced)

[skamster19]

Guten Tag zusammen..

Gleich vorweg: Ja, ich habe per google gesucht, ja, ich habe http://ugpl.de/?q=de/taxonomy/term/48 gefunden. Leider funktioniert das Script anscheinend nicht, zumindest nicht auf meinem Browser (Firefox 2).

Vieleicht liegt das an der Gecko-Engine.. Wie auch immer; ich suche seit einer Weile ein Script, bei dem ich in etwa eine Funktion habe, bei der ich nur Schlüssel und Text eingeben kann und das mir den Entschlüsselten Wert zurückgibt. Es muss Javascript sein, da ich so meine Verbindung sichern will (per Zufallsschlüssel, ganz am Anfang beim Login, um den Privatkey für die RSA-Verschlüsselung, falls möglich, einmalig Clientseitig zu speichern).

Ebenfalls suche ich ein RSA-Script, das eine ähnlich simple Funktion hat. RSA wäre wohl weniger das Problem, falls jemand jedoch gerade eine Empfehlung hat, käme es mir entgegen

Eine schöne Sache wäre es auch, wenn ich Blowfish durch Blowfish Advanced austauschen könnte. Das würde ich jedoch als Nebeneffekt empfinden, Blowfish reicht nach meiner Meinung..

Hoffe auf konstruktive Antworten

Gruss skamster

 

[sw33tlull4by]

Hoert sich jetzt vielleicht etwas pissig an aber RSA kann man leicht selbst Programmieren:
Hier mal ein Kochrezept:
Man erstelle sich eine Zahl n aus dem Produkt 2er sehr sehr grosser Primzahlen.
Anschliessen nimmt man sich eine Zahl e einher, das ist dein oeffentlicher schluessel.
Du hast eine Nachricht x dann gilt fuer die Verschluesselung C():
C(x)=x^e mod n

Fuer die entschluesselung D() brauchst du dann ein passendes b fuer das gilt:
D(C(x))=(x^e mod n)^b mod n = x
Und das war´s dann auch schon.

Duerfte hier jedoch sein, das man 2 sehr grosse Zahlen findet und man testen kann das das Primzahlen sind, und das Testen nimmt Zeit in anspruch.

Das Prinzip dahinter ist das man bei kenntnis von b und n leicht auf e kommt aber bei kennstnis von e und n nur durch rumprobieren auf b.
Was noch zu beachten ist ist das du x so zerlegen solltest das du es im Zahlenraum Z index 3 darstellen kannst, Das heisst:
sei y<=x mit der Eigentschaft y mod n = y d.h. y<n
dies gilt fuer alle yindex j mit:
y index 1+ y index 2+ y index3 .....+yindex q = x^e

und du musst sicherstellen das b das multiplikative Inverse von e in dem Zahlenraum Z index n ist.
Denn dann gilt b*e=1 fuer b,e element von Zindex n mit
ggt(b,n)= 1=ggt(e,n)
mfg

sw33t

P.s.:kleiner tipp noch damit du nicht zuviel Rechenleistung verbraetst:
Du kannst x^e veraendern, dann brauchst du nciht mehr soviel speicher,
denn : wenn gilt
g= y index j + y index j+1 + ...y index k-1 + y index k > n
fuer j,k Element der natuerlichen Zahlen und j <K
Dann kannst du einfach sagen das der neue Wert von g (g mod n) ist denn es gilt=
26 mod 5 = 226 mod 5
In diesem Sinne.

 

[CDW]

bevor sich Elderan&Co melden: bist Du nur an Javasript-Lösung interessiert oder soll das nur irgendeinem Zweck dienen? Vielleicht gibt es bessere/elegantere Methoden, dasselbe zu erreichen

PS: zum Link: funktioniert mit Gecko/20070511 K-Meleon/1.1

 

[Elderan]

Hallo,

Original von skamster19
Eine schöne Sache wäre es auch, wenn ich Blowfish durch Blowfish Advanced austauschen könnte.

Blowfish Advanced ist ein Programm welches verschiedene Algorithmen implementiert, darunter auch Blowfish.

2.
Blowfisch ist relativ rechenlästig um den Verschlüsselungsalgorithmus zu berechnen. Denn bevor du anfangen kannst mit Blowfisch zu verschlüsseln, musst du 4 KB verschlüsseln für den Key (da die S-Boxen Schlüsselabhängig ist).

Deswegen sollte man auch mal Algorithmen testen, die diesen Workload am Anfang nicht haben.
Persönlich bin ich Fan von XTEA

Ansonsten für Algorithmen:
Blowfish
XTEA
RSA

Oder einfach Googlen, man findet genug.

Es muss Javascript sein, da ich so meine Verbindung sichern will (per Zufallsschlüssel, ganz am Anfang beim Login, um den Privatkey für die RSA-Verschlüsselung, falls möglich, einmalig Clientseitig zu speichern).

Soetwas ist relativ schwierig umzusetzen und man braucht schon einiges an Know How um soetwas halbwegs richtig zu implementieren.
Eine Verbindung kann man so nicht komplett sichern, aber z.B. so die Logindaten.

@sw33tlull4by:

Hoert sich jetzt vielleicht etwas pissig an aber RSA kann man leicht selbst Programmieren:

Mit kleinen Zahlen stimmt dies evt., bei Zahlen in der gängigen Größe ist dies aber gar nicht mehr so einfach.
Besitzt man bereits eine Klasse für große Zahlen, ist es nicht mehr ganz so schwer, aber diese auch noch selber schreiben?
Sehr aufwendig und man braucht bereits für x^e mod n eine spezielle Implementierung (modpow), denn erst die Potenz zu berechnen und dann mod zu rechnen ist deutlich zu aufwendig.

Persönlich würde ich mich auch immer entscheiden eine bereits fertige Impl. zu verwenden, zumindest für große Zahlen.
Existiert die bereits, evt. bereits schon in der Prog. sprache, dann kann man darüber nachdenken sie selber zu schreiben, ansonsten wäre er gut beraten eine fertige Impl. zu verwenden.
Vorallem wenn man auch noch Timing Attacken verhindern will

 

[skamster19]

@elderan

Gut, dann habe ich etwas falsch gelesen. Irgendwo stand, das Blowfish Advanced eine Fusion aus Blowfish und Twofish sei. Naja, ich denke, Blowfish alleine tut's auch

Die Sache mit dem Blowfish-JS hat sich nebenbei erledigt, ich hab eins gefunden (http://www.php-einfach.de/sonstiges_generator_blowfish_js.php).

@CWD

Die Idee ist, etwas wie https nachzubauen. Eine Liteversion, sozusagen. Ich weiss noch nicht ganz genau, wie sich Cookies mit dem Server verbinden, sonst wäre die Lösung etwa die: Die RSA-Schlüssel werden mit Blowfish verschlüsselt und übertragen. Den Blowfish-Schlüssel müsste ich irgendwie "verstecken" (evt mit "positionsangaben" im RSA-Key).

Nachdem ich die RSA-Keys im Cookie & Serverseitig als Session gespeichert habe, braucht es Blowfish auch schon nicht mehr. Aber die RSA-Keys müssen Client-Seitig entschlüsselt werden, dh. JS.

Mit RSA könnte ich dann die Daten schön Ver- und entschlüsseln - sofern JS aktiviert ist.

Jeder Schlüssel wird bei jedem Login neu und per Zufall erstellt. So möchte ich einem Mitm-Angriff vorbeugen. mir ist jedoch auch klar, das, wenn jemand den Blowfish-Key und die Verschlüsselten RSA-Keys erwischt, alles schön abhören kann, ist ja bei https nicht unendlich viel sicherer.

Na, soviel zur Idee

PS: auch das Entschlüsseln? Wurde bei mir nix :S

@sw33t

Ich hab gerade ein bischen zu wenig Zeit um das genau durchzugehen, aber versuch es bei gelegenheit trozdem mal.

Und n'grosses ps: verbesserungsideen sind wilkommen!

 

[Elderan]

Hallo,

Original von skamster19
Gut, dann habe ich etwas falsch gelesen. Irgendwo stand, das Blowfish Advanced eine Fusion aus Blowfish und Twofish sei. Naja, ich denke, Blowfish alleine tut's auch

Zwei Verfahren nacheinander anzuwenden macht wenig, da JS nicht wirklich schnell ist.

Lösung etwa die: Die RSA-Schlüssel werden mit Blowfish verschlüsselt und übertragen. Den Blowfish-Schlüssel müsste ich irgendwie "verstecken" (evt mit "positionsangaben" im RSA-Key).

Nachdem ich die RSA-Keys im Cookie & Serverseitig als Session gespeichert habe, braucht es Blowfish auch schon nicht mehr. Aber die RSA-Keys müssen Client-Seitig entschlüsselt werden, dh. JS.

Mit RSA könnte ich dann die Daten schön Ver- und entschlüsseln - sofern JS aktiviert ist.

Dein Verfahren hört sich sehr sehr komisch an.
RSA ist extrem langsam, selbst als C Implementierung. Die Verschlüsselung mit RSA geht noch einigermaßen, aber die Entschlüsselung dauert ewig.
Deswegen tauscht man mit RSA eigentlich nur Sitzungsschlüssel für symmetrische Algorithmen (z.B. AES, Twofish oder Blowfish) aus und die gesamten Daten werden dann mit dem sym. Algorithmus verschlüsselt.

Eine komplett verschlüsselte Verbindung mit JS und Co. zu realisieren erweist sich als recht schwer.
Der Client könnte eine zufälligen Key erstellen und dann mit dem Openkey verschlüsselt an den Server senden.
Der müsste dann mit dem Key alles verschlüsselt zurücksenden und das JS müsste dies dann entschlüsseln und ausgeben.

Was man aber recht leicht machen könnte, ist Formulardaten verschlüsselt zu senden.
Erstellst einen zufälligen Sitzungskey, verschlüsselst den Text mit Blowfish und den Sitzungskey mit RSA.
Das nächste Problem ist aber, einen guten zufälligen Sitzungskey zu generieren. Den Random Generator unter JS kann man i.d.R. vergessen, deswegen könnte man z.B. die Formulardaten hashen, sofern ausreichend Daten vorhanden sind und dies dann als Sitzungsschlüssel verwenden (Funktioniert aber nicht wirklich für das Login Formular).

 

[skamster19]

die schlüssel würden per php generiert.. es braucht für rsa ja keypairs, soweit ich weiss..

also, ich hab rsa-scripte in js gesehn, die haben was innert 1-3 sekunden ver/entschlüsselt..

vieleicht klingt meine methode komsich, aber studier jetzt gut 3 wochen daran rum.. ich mach meine scripte gerne opensource, wenn wer interesse hat, stell ich die lösung sonst zum download bereit..

openkey zieh ich mir sonst gerne mal rein, davon hab ich noch nichts gehört..

mh, die formulardaten hashen?

da seh ich das problem darin, das, wenn ich einen text wieder lesen möchte, den ich übertrage, nicht mehr in den klartext bekomme..

was ich vieleicht übertrieben formuliert habe: nicht die ganze verbindung ist verschlüsselt, aber alle relevanten dinge. wenn der mitm noch <html><head><title>website</tile> sieht, ist mir das relativ egal..

edit:

ich hatte noch eine idee mehr und hab versucht, sie mal aufzuzeichnen:

http://195.141.111.127/crypt.pdf

hoffentlich ist's einigermassen verständlich

 

[Elderan]

Hallo,

Original von skamster19
openkey zieh ich mir sonst gerne mal rein, davon hab ich noch nichts gehört..

Bei asymmetrischen Verfahren unterscheidet man zwischen öffentlichen (public) und privaten (private) Schlüsseln.
Openkey war hier das falsche Wort.

mh, die formulardaten hashen?

da seh ich das problem darin, das, wenn ich einen text wieder lesen möchte, den ich übertrage, nicht mehr in den klartext bekomme..

Nein, so wars nicht gedacht.
Du brauchst für einen zufälligen Sitzungsschlüssel einen guten Zufallsgenerator. Auf den von JS würde ich mich nicht verlassen.
Deswegen kann man als Sitzungsschlüssel folgendes verwenden:
md5([Formulareingaben] + [Infos über User, OS, Browser, Auflösung etc.] + [JS Random Generator])

Oft kann man davon ausgehen, dass ein Lauscher nicht wissen kann, was so in einem Formular eingegeben wurde.
Hier beim Login wäre es z.B. nur Elderan, also erratbar und nicht wirklich brauchbar, dieser Posts hier würde aber einen guten zufälligen Sitzungsschlüssel ergeben, sofern er nicht öffentlich einsehbar danach wäre.

also, ich hab rsa-scripte in js gesehn, die haben was innert 1-3 sekunden ver/entschlüsselt..

Was unglaublich lange ist.
In RSA wird eine Text in Blöcke aufgeteilt, da da x nicht größer sein darf als das n.
Wenn du also einen 1024 Bit (public) Key hast, könnte man höchstens auf 1023 Bit Blöcke zurückgegriffen (hochwertigste Bit ist 0), bzw. 127 Byte Blöcke.

Wenn du also für 127 Byte z.B. 3 Sekunden brauchst, brauchst für 14 kb (die akt. Seite hier) schon knapp 300 Sekunden.
Des Weiteren ist es so, dass das verschlüsseln in RSA extrem viel schneller geht als das entschlüsseln, einfach aufgrund des deutlich kleineren Exponenten.

Du musst bei den Demos auch drauf achten, welche Länge der Key hat.
Wenn du einen 512 Bit Key hast, dann geht das ver/entschlüsseln deutlich schneller als wenn du einen 1024 Bit Key benutzt.

Aber, eine 512 Bit Key lässt sich heute doch relativ schnell brechen (faktorisieren), so dass dieser keine allzugroße Sicherheit bietet.
Im November 2005 konnte sogar RSA-640, ein 640 Bit Key, gebrochen werden, deswegen sollte man mindestens 768 Bit Keys verwenden, oder doch lieber 1024. Aber wie gesagt, dort steigt dann auch der Rechenaufwand für dich stark an.

Wie gesagt, einen Text in RSA zu verschlüsseln macht normalerweise keiner, sondern man Verschlüsselt den Text mit einem sym. Algorithmus und nur den zufälligen Sitzungskey mit RSA.

(PS: Evt. wäre es auch eine Idee, dass Diffie Hellman-Protokoll zu verwenden mit bekannten Paramater für p und g, gewählt nach rfc2412 Page 45)

 

[skamster19]

http://www-cs-students.stanford.edu/~tjw/jsbn/rsa2.html

dort hat eine 1024-bit-entschlüsselung ca 1.3 sekunden.. und ich hab "nur" einen 1.8 ghz-prozessor.. mein computer wär etwa um 2-3 jahre überholt..

512-bits brauchen sogar nur 222 ms zum entschlüsseln.

was vieleicht noch zu sagen ist: empfindlichere sachen wie passwort u.ä werden vor dem verschlüsseln vorgehasht (derzeit zwar "nur" mit sha1, aber dort hab ich zeitlich mehr probleme, bei allem, was über md5 ist und mit js ausgeführt wird).

und da der schlüssel jedes mal neu erstellt wird, sehe ich die gefahr mit einem 512bit-key nicht so sehr, wenn ich ehrlich bin. wie lange ist ein benutzer normalerweise online?

und wie lange hat man, bis der key geknackt ist?

ich lasse mich gerne eines besseren belehren, aber ich denke, die zeit, bis der key geknackt ist, reicht nicht..

gut, die daten könnten gespeichert und auf dem computer des crackers angesehen werden.. aber nur für eine session.. oder wäre die sicherheitsidee dann doch zu lasch?

sollte ich doch besser 1024 bits verwenden? irgendwie möchte ich ja meine programme vom aufwand des rechners her einigermassen optimal halten, jedoch auch eine vertretbare sicherheit verwenden.

was vieleicht auch noch zu beachten ist: der cracker müsste zwei schlüssel / session knacken (siehe pdf)..

 

[Elderan]

Hallo,

dort hat eine 1024-bit-entschlüsselung ca 1.3 sekunden

Ja, und was passiert wenn du mal etwas mehr als 1 Wort verschlüsselst/entschlüsselst?
Wie gesagt, man kann bei 1024 max. 127 Byte pro Durchgang verschlüsseln.
Dein letzter Post hat rund 1000 Zeichen, also knapp 10 Blöcke, also rund 18 Sekunden (wobei der JavaScript vorher abbricht).

Original von skamster19
was vieleicht noch zu sagen ist: empfindlichere sachen wie passwort u.ä werden vor dem verschlüsseln vorgehasht

Hier muss man aber vorallem replay Attacken ausschließen, sowie besteht dort die Gefahr, dass es ausreicht, den Hash zu kenne um sich einzuloggen.

Aber ich hab mir gerade dein dein 'Paper' angeguckt, und ehrlich gesagt, es ist mist. Zuerst einmal ignorierst du scheinbar konsequent den Nutzen von symmetrischen Algorithmen.
Dann, wie du dort schon erwähnt hast, ist die erste Übergabe extrem unsicher.
Wenn ich den gesamten Verkehr mitschneide, erhalte ich den private Key des Users...

Evt. zuerst lesen, wie Schlüsselaustausch-Verfahren funktionieren und versuchen dieses nachzuempfinden.
Ein Blick wie SSL arbeitet dürfte auch nicht schaden.

Im Groben sollte es so sein (mit z.B. RSA):
1. Server sendet an den User seinen (festen und sicheren) public Key sowie eine zufällige Zahl.
2. Der Client erstellt einen zufälligen Wert, indem er folgendes bildet:
md5([Userinfos] + [Zufallszahlen] + [Was sonst noch so da ist])
Dieses verschlüsselt er mit dem public Key des Servers.
Der Sitzungsschlüssel ist dann: md5([Zahl vom Server] + md5([Userinfos] + [Zufallsdaten]+ [Was sonst noch so da ist]))
3. Der Client sendet seinen zufälligen Wert an den Server, der Server kann dann damit den Sitzungsschlüssel berechnen und speichert den Key in einer Session.

Alternativ mit Diffie-Hellman (ich mag das Verfahren):
1. Server bildet g^x mod p, g und p sind fest, x muss zufällig sein (hier wieder das Problem mit guten Zufallszahlen, wenn man auf /dev/urandom zugreifen ideal).
Das Ergebnis sendet er an den Client (steht im JS was an den Client gesendet wird).
2. Der Client bildet eine Zufallszahl y (kann wie unter 2. bei RSA berechnet werden), berechnet g^y mod p, und kann den (zufälligen) Sitzungsschlüssel damit errechnen, welcher abgespeichert wird.
An den Server muss er nur noch g^y mod p übertragen, sowie die verschlüsselten Daten mit dem Sitzungsschlüssel (+ sym. Verfahren).
3. Der Server hat in einer Session sein g^x mod p abgespeichert, kann durch das g^y mod p an den gleichen Sitzungsschlüssel gelangen und die Daten entschlüsseln.


Der gesamte Verkehr läuft nur noch verschlüsselt über einen symmetrischen Algorithmus (z.B. Blowfish o.ä., evt. die Sboxen direkt im Cookie/Session abspeichern).
Soetwas ist nicht nur extrem viel schneller, sondern auch deutlich leichter umzusetzen.
Das größte Problem ist, an gute Zufallsdaten zu kommen.
Dies lässt sich aber zumindest halbwegs in den Griff bekommen, wenn man Diffie-Hellman verwendet und der Server halbwegs gute Zufallszahlen erstellt.

und da der schlüssel jedes mal neu erstellt wird, sehe ich die gefahr mit einem 512bit-key nicht so sehr, wenn ich ehrlich bin. wie lange ist ein benutzer normalerweise online?

Du hast wie gesagt, das Problem mit dem erstellen von Zufallsdaten.
Wenn du die Standardzufallsgeneratoren von PHP verwendest um ein zufälliges Keypair zu erstellen, dann existieren nur rund 4 Mrd. solcher Paare.
Das man diese alle schnell durchtesten kann, bzw. sogar abspeichern kann, sollte klar sein.

gut, die daten könnten gespeichert und auf dem computer des crackers angesehen werden.. aber nur für eine session.. oder wäre die sicherheitsidee dann doch zu lasch?

RSA-155, ein 512 Bit starker RSA-Key wurde 1999 faktorisiert.
Wie im RSA Bericht zu lesen, war der Rechenaufwand rund 8000 MIPS Jahre.
Ein Intel Core 2 Extreme QX6700 schafft rund 57000 MIPS, d.h. dieser wäre knapp 50 Tage mit der Faktorisierung beschäftigt.
Spann ich ein paar Computer ein, schaffen die das in wenigen Tagen.

Es kommt drauf an, was in deiner Session so übertragen wird. Wenn eine geknackte Session dazu führt, dass der Angreifer z.B. das Passwort erhählt, dann sind 512 Bit eindeutig zuwenig.


Aber deinen Ansatz sollte man eh nicht wählen. Dein Protokoll ist sehr unsicher und weist große Mängel auf, solch eine Seite wäre extrem langsam und die Implementierung ist viel zu aufwendig

Edit
Man hat das Problem, wie man in JS Daten lokal abspeichert.
Wenn man in JS ein Cookie setzt, so wird dieses im Klartext das nächste mal an den Server gesendet.
Zur Not müsste der Client bei jedem Seitenaufruf einen neues Sitzungsschlüssel erstellen und dem Server mitteilen, wäre aber unnötig rechenintensiv und eine Lösung über die lokale Speicherung, sofern in JS möglich, wäre besser.

 

[skamster19]

oh, jetzt hat's bei mir ein grosses klickgeräusch gegeben..

ich dank dir tausend mal für die erklärung, jetzt wird mir vieles leichter fallen..

noch so eine frage, wenn du dich so gut in der kryptographie verstehst..

wegen dem zufälligen key.. meine idee ist etwas in der richtung:

	function gen_key(){
		$key = $_SERVER['REMOTE_ADDR'];
		$key .= md5(rand(rand(-3,-11), rand(-11, rand(-12, -443255))));
		$key .= $_SERVER["HTTP_USER_AGENT"];
		$key .= crc32(rand(3, rand(11, rand(12, 443255))));
		$key = sha1($key);
		$key = substr($key, 0, rand(4, 40));
		return $key;
	}

function gen_keyf(php_value) {
var gen_key = Math.random() * Math.random() + screen.colorDepth * screen.availHeight / Math.random() + screen.availWidth;
gen_key += document.URL;
gen_key += php_value;
gen_key += document.defaultCharset;
gen_key += document.lastModified
gen_key += MD5(Math.random()+navigator.userAgent);
gen_key = MD5(gen_key);
document.write(gen_key);
document.write("php-value: "+php_value);
}
gen_keyf("<? echo($cr->gen_key()); ?>");

ich hätte mir in etwa so was ausgedacht.. document.write müsste natürlich weggelassen werden, die funktion zum speichern im cookie dafür hinzugefügt..

denkst du, das dies "zufällig" genug ist?

http://195.141.111.127/cracktech/projects/money/test.php

 

[Elderan]

Hallo,

beziehe mich auf PHP:
Man sollte etwas verwenden, was dem Angreifer nicht bekannt ist. Du möchtest ja verhindern, dass ein Lauscher den Text versteht, den er dort sieht.
Allerdings $_SERVER["HTTP_USER_AGENT"]; und $_SERVER['REMOTE_ADDR']; werden ja bei jeder Seitenanfrage im Klartext übertragen, so dass diese die Sicherheit nicht erhöhen.

Außerdem macht die rand-Anweisung mit zufälligen Grenzen wenig Sinn, senkt sehr stark die Sicherheit deiner App.

Du musst Sachen verwenden, die nur dem Server bekannt sind.
Ideal wäre es, wenn du mit fopen() z.B. 16 Byte aus /dev/urandom lesen kannst. Ob dies geht, hängt natürlich immer vom Provider ab.
Sollte dies nicht gehen, kann man evt. Alternativ auf mcrypt zurückgreifen.
Entweder so:
$rand_sicher = mcrypt_create_iv(16, MCRYPT_DEV_URANDOM );

Hier darf nicht MCRYPT_RAND als Konstante übergeben werden.

Ansonsten am besten soviel verwenden wie du bekommen kannst, z.B. so:

<?php
//Muss natürlich noch Fehlertolerant gemacht werden, also nicht existieren Funktionen abfangen etc.
function gen_key() {
  if($kann_dev_urandom_auslesen)
    return $bytes_aus_dev_urandom;
  else if($mcrypt_geladen_und_kann_MCRYPT_DEV_URANDOM)
   return mcrypt_create_iv(16, MCRYPT_DEV_URANDOM ); 
 else {
   if($php_version_zu_alt) {
      //srand und mt_srand aufrufen, ansonsten nicht!
   }
   $key = "geheime, zufällige Konstante, nur die bekannt";
   $key .= rand().mt_rand().rand().mt_rand();
   $key .= microtime();
   $key .= @getmygid().@getmyuid().@getmypid().@get_current_user().@getmyinode().@getlastmod().@getmyinode().get_current_user();
  if(function_exists("getrusage"))
     $key .= implode("",@getrusage());

   $key .= memory_get_usage().memory_get_peak_usage(); 
   $key .= php_uname();
   $key .= implode("",get_defined_constants());
   $key .= implode("",get_defined_vars());
   $key .= microtime();
   

   return pack("h*", md5($key))

   }

}

Dies sollte relativ gute Werte liefern, sonfern man davon ausgeht, der Angreifer hat keine Möglichkeit diese konstanten Werte zu erfahren.
Wenn der Angreifer dort selber Webspace haben kann oder auf eine phpinfo() Datei zugriff hat, dann ist der Schutz auch wieder nur suboptimal.


JavaScript
Du solltest nicht soviel Rechnen, also keine Multiplikationen und Divisionen durchführen sondern einfach die einzelnen Werte aneinander hängen und dann den Md5 Hash Wert bilden.

Also z.B. so:
tempdate = new Date() ;
var string = Math.random() +""+ Math.random() +"" +screen.width + "x" + screen.height+ ""+screen.availHeight+""+screen.availWidth +""+screen.colorDepth+""+window.screenX+""+window.screenY+""+tempdate.toLocaleString();

key = md5(string);

Es gibt noch weitere Sachen die man in JS abfragen kann, z.B. welche Erweiterungen geladen sind, diese mit einzubauen ist nicht schlecht.


Aber achte auf das Edit zum Thema Cookie, dies bereitet große Probleme.