[cryptografische algoritmes] Bodacion

dinsdag 5 maart 2002 10:59

Z.O.Z.

Op maandag 04 maart 2002 18:20 schreef Otis het volgende:
Allemaal leuk, maar WAT doen ze met die nummers? Het probleem is nl. niet of de encryptie goed genoeg is, maar of men via slinkse wijze niet op die bak kan komen en zo de encryptie te omzeilen.

Doet me denken aan de meest fantastische copy protection schema's waarbij in de code ergens staat:
code:
1
2
3
4
5
6
bool bResult = CheckCopyProtection();

if(!bResult)
{
     // copy. abort
}
waarbij men niet het complete copy protection schema gaat kraken, maar botweg de test uitcomment (ik heb het even in C geplaatst hierboven, maar dat 'uitcommenten' doe je natuurlijk dan in een disassembly door NOPs erovereen te plakken) met NOPs.

NOP: 0x90 ;-)

Dat is waar, maar niet remote-exploitable. Wat hier staat is nog geen encryptie. De sleutels zijn doorgaans niet het probleem, de encryptie is dat wel! Het eenvoudigweg x-orren is vaak voldoende, maar als dit op meer documenten wordt toegepast, kun je met statistieken en 'know-text', zonder de sleutel de boel decoderen.
Veel encryptiemethoden hebben deze zwakheden niet meer, omdat er meer wordt gedaan dan xor. Denk aan xor met de encryptie-serie én met de vorige byte, dit stuurt de meeste statistische methoden het riet in...

Op maandag 04 maart 2002 18:20 schreef Otis het volgende:
Een volledige random reeks getallen is overigens erg moeilijk te genereren, want je seeds zijn zelden random. Echter je kunt dmv het combineren van een aantal bijna random seeds (electronenstraal positie monitor, clock pulses since boot, etc) een seed genereren die vrijwel volmaakt random is en daarmee een rijtje getallen genereren. In feite dus onmogelijk te raden wat het volgende getal wordt. Maar nogmaals; wat heb je aan de info als je weet wat het volgende getal wordt? Kun je dan meteen de handel decrypten of niet? Want dat is me niet duidelijk.

Random bestaat niet. punt.
Als je een dobbelsteen gooit, en je weet alle omgevingsparameters (gewicht + vorm dobbelsteen, zwaartekracht, hoogte, structuur ondergrond, ...) dan kun je voorspellen wat je gaat gooien.
Gelukkig hebben we zelden échte random getallen nodig, onbegrijpelijke series zijn voldoende. Als we een bepaald proces niet tot in de puntjes begrijpen, levert dit voor mensen informatie op die enorm 'random' lijkt te zijn. Net als dat chinees voor mijn idee willekeurige klanken zijn. (NFI

)
Momenteel begrijpen we nog erg weinig van radioactief verval, daar kun je dus een serie op baseren. Direct gebruiken voor encrytie is niet erg handig, want voor encryptie moet je een bekende reeks hebben. (!)

Seed & Serie
Bij random getallen bestaan er twee belangrijke begrippen. Seed en Serie. De seed is een getal waar de serie op gebaseerd is. Hoe willekeuriger het getal, hoe willekeuriger de serie.
Stel: ik heb een formule om een serie te genereren:

code:

f(x) -> (f(x-1) * 2) % 10
(% == modulus == rest na deling.)

De seed f(0) = 1
Mijn reeks wordt dan:
1 2 4 8 6 2 4 8 6 2 4 8 6 2 4 8 6
Een andere seed levert op:
3 6 2 4 8 6 2 4 8 6 2 4 8 6 2 4 8

Zoals je ziet is mijn reeks niet erg sterk.

Stel de volgende formules:

code:

1
2
3

g(x) -> g(x-1) + 1
f(x) -> fix(g(x-1)/10 + g(x)) % 10
(fix betekent afkappen, ook wel INT genoemd)

Zoals je willicht ziet is de reeks van g bij een seed 9 de volgende:
9 10 11 12 13 14 15 16 17 18 19 20 21
De echte reeks f is dan
? 1 2 3 4 5 6 7 8 9 0 1 3

Als de formule niet bekend is, is het een zeer moeilijk karwij om de formule te achterhalen. Maar: als je de formule weet, kun je al een stuk meer. Als je de waarde 3 krijgt, en je weet (toevallig) dat de seed niet zo groot was, dan weet je bijna zeker dat die gevolgd wordt door 4.
Als je echter de waarde 1 krijg, weet je niet of die gevolgd wordt door een 2 of door een 3.

Waar nu deze westrijd om gaat is om ZONDER de seed de formule (en zijn parameters) te achterhalen. Op zich is dat onzin. Die formule wordt een keer bekend. Het wordt dan de grap om de seed te vinden aan de hand van de gegeven getallen icm de formule. Als je dat kan, dan is het kraken van een beveiliging een eitje geworden.

Daadwerkelijke encrytie
Ik noemde al XOR als encryptiemethode. Die werkt als volgt:

code:

-Coderen-
origineel: 00100100
code:   10010110 <- deze komt uit zo'n reeks
XOR----------------
resultaat: 10110010

-Decoderen:
ingekomen: 10110010
code:   10010110 <- uit dezelfde reeks!
XOR----------------
origineel: 00100100

het is er dus op gebaseerd dat beide partijen de 'code' kennen, de eerder genoemde reeks. Zonder die code kom je niet ver.
Nu is het erg veel werk om zo'n code in zijn geheel over te sturen, dus stuur je alleen de sleutel over: of beter nog, die stuur je helemaal niet over, want als een aftappende partij de sleutel ziet, kan hij de rest van de verbinding ook decoderen.
(ik sla hier nu een heel belanrijk deel over: public & private keys - Dat is denk ik de complex voor /14, en bovendien snap ik het niet goed genoeg om het hier uit te leggen. Als iemand het wel snapt: voel je vrij)

disclaimer

Bij de bovenstaande formules is het kraken van de seed met brute-force een eitje. Het lijkt me niet verstandig om die écht toe te gaan passen. In Real Life wordt er echter gebruik gemaakt van veel grotere seeds (sleutels), die niet met brute force te kraken zijn.

Localhost, sweet localhost

Acties:

MSalters

Op dinsdag 05 maart 2002 10:01 schreef kvdveer het volgende:

Random bestaat niet. punt.
Als je een dobbelsteen gooit, en je weet alle omgevingsparameters (gewicht + vorm dobbelsteen, zwaartekracht, hoogte, structuur ondergrond, ...) dan kun je voorspellen wat je gaat gooien.

Random bestaat wel. Punt.

Als je een dobbelsteen gooit, dan heb je altijd te maken met (1) quantummechanische fluctuaties; volgens de chaostheorie kan de kleinste fluctuatie onbeperkt groeien tot het punt waar de dobbelsteen omrolt, en (2) Heisenbergs onzekerheids principe, wat betekent dat je nooit alle parameters 100% zeker weet - sterker nog, als je er een 100% zeker weet is er altijd een andere waar je niets van weet.

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein

dinsdag 5 maart 2002 11:01

Acties:

MSalters

Leuk, dat er nooit twee dezelfde reeksen worden gegenereerd.
Dus als ik een reeks van 4 getallen onder de 256 genereer, dan crasht m'n compu na 256^4 reeksen.
Dat verklaart Windows

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein

dinsdag 5 maart 2002 11:05

Acties:

dinsdag 5 maart 2002 11:11

Z.O.Z.

Op dinsdag 05 maart 2002 11:01 schreef MSalters het volgende:
Leuk, dat er nooit twee dezelfde reeksen worden gegenereerd.
Dus als ik een reeks van 4 getallen onder de 256 genereer, dan crasht m'n compu na 256^4 reeksen.
Dat verklaart Windows

Noch klok noch klepel?

Waar heb je het over?

Localhost, sweet localhost

Acties:

dinsdag 5 maart 2002 11:15

Z.O.Z.

Op dinsdag 05 maart 2002 10:59 schreef MSalters het volgende:

[..]

Random bestaat wel. Punt.

Als je een dobbelsteen gooit, dan heb je altijd te maken met (1) quantummechanische fluctuaties; volgens de chaostheorie kan de kleinste fluctuatie onbeperkt groeien tot het punt waar de dobbelsteen omrolt, en (2) Heisenbergs onzekerheids principe, wat betekent dat je nooit alle parameters 100% zeker weet - sterker nog, als je er een 100% zeker weet is er altijd een andere waar je niets van weet.

Heidelberg... I love this guy. Inderdaad heeft die gozer datgene gezegd wat jij hier aanhaalt, maar dat spreek ik ook niet tegen. De quantum-mechanische fluctuaties zijn ook gebonden aan natuurwetten. Wij mensen zuller er echter nooit iets mee kunnen omdat we die parameters niet kennen. Voor ons mensen is het dus random genoeg, maar in werkelijkheid is het niet random.
Een gedeelte van heidelberg's principes zijn trouwens gebaseerd op het kansprincipe wat Schreudinger al aangaf met zijn kat... Het ontbreken van informatie maakt iets random.
Dit kun je weer terugtrekken naar die dobbelsteen. Die is random omdat ik niet weet hoe zwaar die dobbelsteen is, en omdat ik niet weet hoe 'ie precies gegooid gaat worden. Voor mijn doeleinden is dat dus voldoende.

ps. mag de discussie trouwens weer gaan over cryptografie... Het is geen W&L topic...

Localhost, sweet localhost

Acties:

dinsdag 5 maart 2002 11:17

Hmm, geen zin om die hele serie door te kijken, maar is er uberhaupt wel een regel te vinden zonder een X er in?

Acties:

dinsdag 5 maart 2002 11:18

Het verhaal gaat zo natuurlijk wel een beetje offtopic, maar aangezien het doel van de topicstarter een beetje hooggegrepen is (ik wed dat niemand hier, ik zelf incluis hier ook maar een flauw benul heeft van hoe "biomorphic mathematics" werken) vind IK dat niet zo erg. Ik vind cryptografie erg boeiend.

Ik zal daarom een stukje toevoegen aan kvdveer's verhaal:

Secret vs. Public key cryptografie.

Wat is het?
Tja, dat lijkt me duidelijk, in secret key cryptografie wordt een sleutel gebruikt die alleen bekend is bij de verzendende en ontvangende partij. De sleutel is symetrisch, dat wil zeggen dat de (geheime) sleutel gebruikt kan worden om berichten de versleutelen EN te ontsleutelen. Zodra een "vijand" dus je geheime sleutel heeft ben je genaaid, hij kan dan jouw berichten lezen (da's kut) en hij kan (geheel tegen jouw verwachtingen in) berichten sturen die jij niet kunt onderscheiden van berichten van personen waarvan jij weet dat ze je sleutel hebben (kan nog veeeel erger zijn)
Voorbeelden van secret key crypto zijn: DES, 3DES en AES. Sleutel lengte lopen typisch uiteen van 56 bits (DES) tot 256 bits (AES) en het kraken van de beveiliging houdt typisch in dat ALLE mogelijke sleutels van de gebruikte lengte geprobeerd moeten worden.

In public key cryptografie bestaat de sleutel uit twee delen. Een publiek deel, dat iedereen dus mag weten en wat gebruikt wordt om berichten te versleutelen. En een secret deel, wat alleen bekend is bij de ontvangende partij en wat nodig is om berichten te ontsleutelen. Iedereen kan nu dus berichten versturen, maar deze keer WEET je dat en dus moet je andere maatregelen treffen om vertrouwde partijen van vijanden te onderscheiden. Voorbeelden van public key crypto zijn: RSA (duh) en ECC (elliptic curve crypto). De sleutel lengtes lopen sterk uiteen. Is tegenwoordig bij RSA een sleutel lengte van 1024-2048 bits nodig, bij ECC is een sleutel lengte van rond de 200 bits al voldoende. De methoden om public key crypto te kraken lopen ook erg uiteen. RSA kraken komt neer op het factoriseren van een enorm getal en ECC hangt samen met het discrete logaritme probleem.

RC5 kickt ass, waarom hebben we die public key crypto eigenlijk nodig???
Het d.net project heeft wel aangetoond dat secret key crypto ERG veilig is (modulo alle kennis die de NSA misschien heeft waar gewone stervelingen niets van weten

). Waarom hebben we dan nog public key crypto nodig? Door de enorme sleutel lengte of complexe wiskundige achtergrond is public key crypto namelijk ook nog eens een stuk trager dan secret key. Het grote nadeel van secret key crypto is dat er haast geen veilig manier is om keys te distribueren. Banken kunnen hun keys natuurlijk met een gewapend transport tussen de verschillende filialen distribueren (ik noem maar een zijstraat), maar je kunt moeilijk een geavanceerd crypto systeem instaleren en dan de sleutels ervan gewoon naar al je vertrouwde partijen mailen. Met public key crypto gaat dit wel heel eenvoudig. Iedereen maakt zijn public key openbaar en dan is iedereen in staat elkaar versleutelde berichten te sturen, precies wat je zou willen. Maar met name door de bovenstaande efficientie overwegingen wordt er vaak gekozen voor een gemengde aanpak. In zo'n geval genereerd de versturende partij een random secret key. Hiermee wordt het bericht versleuteld. De secret key wordt vervolgens versleuteld met de public key van de ontvangende partij. Het geheel (versleuteld bericht + versleutelde sleutel) wordt vervolgens naar de ontvanger verstuurd. De ontvanger ontsleuteld de secret key en ontsleuteld daarmee het bericht. Dit is zowel veilig als efficient.

_{[quote]

Op dinsdag 05 maart 2002 11:29 schreef pblom het volgende:

[..]

Public-key cryptografie is nodig omdat bij symetrische cryptografie je erg snel door je key-space bent. Je moet immers met iedereen waarmee je communiceert een nieuwe geheime sleutel afspreken.

[..]

[/quote]

Dit is natuurlijk géén probleem. De veiligheid van secret key crypto komt juist van het feit dat er zo ontiegelijk veel sleutels zijn. Zelfs met een onveilige 56 bits sleutel zijn er al 72057594037927936 sleutels. Hoeveel vrienden heb jij En al zouden er op de hele wereld mensen zijn die de zelfde sleutel gebruiken? Als je dat niet weet, zul je toch de hele keyspace moeten doorzoeken.}

Waar komen deze super random series dan in het verhaal?

Er is een cryptografie die absoluut onkraakbaar is, mits de gebruikte key maar precies 1 keer wordt gebruikt. Onkraakbaar betekend hier dat het absoluut onmogelijk is (zelfs bruteforce) om gegeven een gecodeerde tekst, de originele tekst te achterhalen. Dit is de zogenaamde "one-time-pad"-methode. In deze methode wordt de te coderen tekst ge-XORed met een een pseudorandom reeks (de sleutel). De ontvangende partij moet de gecodeerde tekst XORen met de sleutel om het originele bericht terug te krijgen. Als de sleutel maar precies 1 keer wordt gebruikt is deze methode onkraakbaar omdat XORen van het gecodeerde bericht met alle mogelijke sleutels alle mogelijke originele berichten oplevert, een aanvaller kan nooit weten wat het echte origineel is.

voorbeeld.
Stel ik codeer de zin "Dag schat, wat eten we???" door te XORen met "ewixlsqovmdoaxpiebwbthskq" en een aanvaller gaat brute force de code tekst met alle mogelijke sleutels XORen. Dan zal hij op een gegeven moment de volgende originele tekst vinden: "Morgen gaat het WTC plat!" evenals alle andere strings ter lengte 25. Welke het echte origineel is kun je nooit weten.

Het probleem is dus dat zowel de sturende als de ontvangende partij telkens dezelfde pseudorandom sleutel moeten hebben. Deze kun je natuurlijk gecodeerd mee sturen met het bericht, maar dan is je beveiliging slechts zo sterk als de beveiliging van de gecodeerde sleutel en dus niet meer onkraakbaar. In plaats daarvan zou het leuk zijn als beide kanten dezelfde, maar wel zeer random reeks kunnen genereren. Dan hoeft deze methode maar één keer geseed te worden, waarna beide partijen dezelfde random reeks kunnen produceren waarmee ze one-time-pads kunnen genereren. Er zitten natuurlijk nog wel wat haken en ogen aan deze methode, omdat je voor elke persoon waar je mee communiceert een aparte reeks bij moet houden, maar dat zijn wel dingen op te vinden. Het is belangrijk dat een aanvaller niet de reeks kan voorspellen (ook niet als ie op één of andere manier een deel van de gegenereerde reeks in handen krijgt), want dan is je onkraakbare cryptografie gekraakt.

He who knows only his own side of the case knows little of that.

Acties:

Grum

code:

1 2	erik@knife:~$ lynx --source http://www.silentsnow.homestead.com/files/bodacion.txt \| grep -v '<' \| grep -v X \| wc -l 0

nope

dinsdag 5 maart 2002 11:20

Acties:

dinsdag 5 maart 2002 11:22

Op dinsdag 05 maart 2002 11:18 schreef Grum het volgende:
code:
1
2
erik@knife:~$ lynx --source http://www.silentsnow.homestead.com/files/bodacion.txt | grep -v '<' | grep -v X | wc -l
    0
nope

Haha, ok

Zou de 1000e dan ook een X bevatten?!

Acties:

dinsdag 5 maart 2002 11:23

Niet dat het echt boeit, omdat het om de 1000e gaat (1e in nieuwe reeks), maar het 2e 'getal' is altijd 3 keer achter elkaar hetzelfde.

Acties:

pblom

Je bent wel degelijk goeie random getallen nodig.

Hoe random-mer de getallen zijn, waarmee je keys genereerd, hoe kleiner de kans is dat er 2 dezelfde keys bestaan.

dinsdag 5 maart 2002 11:29

Acties:

eNaSnI

Komen de 2 en de X in iedere code voor??

Wie zoekt, zal vinden http://www.google.com

dinsdag 5 maart 2002 11:29

Acties:

pblom

Op dinsdag 05 maart 2002 11:17 schreef RickN het volgende:

...

RC5 kickt ass, waarom hebben we die public key crypto eigenlijk nodig???

[to be continued]

Public-key cryptografie is nodig omdat bij symetrische cryptografie je erg snel door je key-space bent. Je moet immers met iedereen waarmee je communiceert een nieuwe geheime sleutel afspreken.
Met public-key crypto kan iedereen berichten die voor jouw bestemt zijn met jouw public-key encrypten, je hoeft niet meer met iedereen apart een sleutel af te spreken.

dinsdag 5 maart 2002 11:31

Acties:

dinsdag 5 maart 2002 11:40

Op dinsdag 05 maart 2002 11:29 schreef eNaSnI het volgende:
Komen de 2 en de X in iedere code voor??

De 2 de G en de F.

edit:
Dus niet de X

Acties:

dinsdag 5 maart 2002 11:43

Lakse Perfectionist

Het 2e getal wordt een 8.

Volgens mij kan je wel een regelmaat vinden in deze getallen, maar ik heb daar de tijd/beheofte niet voor. Het 2e getal is in ieder geval niet random, dus is de hele serie niet random.

Acties:

dinsdag 5 maart 2002 11:44

Op dinsdag 05 maart 2002 11:40 schreef mr_obb het volgende:
Het 2e getal wordt een 8.

Volgens mij kan je wel een regelmaat vinden in deze getallen, maar ik heb daar de tijd/beheofte niet voor. Het 2e getal is in ieder geval niet random, dus is de hele serie niet random.

Hmm netjes

hoe kom je hier aan?

Acties:

dinsdag 5 maart 2002 11:48

Laat maar.

He who knows only his own side of the case knows little of that.

Acties:

dinsdag 5 maart 2002 12:12

Lakse Perfectionist

Op dinsdag 05 maart 2002 11:43 schreef Dash2in1 het volgende:

[..]

Hmm netjes hoe kom je hier aan?

Gokje

Ik was even snel aan het kijken en het viel me op dat de tweede letter een reeks doorloopt. Die is als volgt:

code:

5hvjk grstt 284ya z6pc3 newd7 bfm9u qlx
5hvjk grst2 84yaz 6pc3n ewd7b fm9uq lx
5hvjk grst2 84yaz 6pc3n ewd7b fm9uq lx
5hvjk grst2 84yaz 6pc3n ewd7b fm9uq lx
5hvjk grst2 84yaz 6pc3n ewd7b fm9uq lx
5hvjj kgrst 284ya z6pc3 newd7 bfm9u qlx

De letters hierboven zijn de tweede letter van de code, en worden telkens 3 keer herhaald. De enige onregelmaat zit hem bij de eerste T en de 6e J, die komen namelijk 6 keer achter elkaar (in de reeks hierboven weergegeven met een dubbele t en dubbele J). Ik ga nog ff verder met de reeks. Misschien zit er ook regelmaat in de dubbele letters?

Acties:

Verwijderd

Op dinsdag 05 maart 2002 11:15 schreef Dash2in1 het volgende:
Hmm, geen zin om die hele serie door te kijken, maar is er uberhaupt wel een regel te vinden zonder een X er in?

Bekijk voor de gein eens de laatste 4

dinsdag 5 maart 2002 12:15

Acties:

Verwijderd

van die site: A bodacion is a character representation of a large number generated using poweful mathmatics to be difficult to guess.

Het grote getal dat powerfull moet voorstellen was waarschijnlijk net niet groot genoeg

dinsdag 5 maart 2002 12:15

Acties:

dinsdag 5 maart 2002 12:30

Lakse Perfectionist

Ok, ik heb dus de hele reeks van de tweede letter doorlopen. De tweede letter doorloopt de volgende reeks, waarbij iedere letter 3 keer voorkomt:

code:

5hvjk grstt 284ya z6pc3 newd7 bfm9u qlx
5hvjk grst2 84yaz 6pc3n ewd7b fm9uq lx
5hvjk grst2 84yaz 6pc3n ewd7b fm9uq lx
5hvjk grst2 84yaz 6pc3n ewd7b fm9uq lx
5hvjk grst2 84yaz 6pc3n ewd7b fm9uq lx
5hvjj kgrst 284ya z6pc3 newd7 bfm9u qlx
5hvjk grst2 84yaz 6pc3n ewd7b fm9uq lx
5hvjk grst2 84yaz 6pc3n ewd7b fm9uq lx
5hvjk grst2 84yaz 6pc3n ewd7b fm9uq lx
5hvjk grst2 84yaz 6pc3n eewd7 bfm9u qlx
5hvjk grst2

Kan iemand een programmaatje schrijven dat alle 1e, 3e, 4e, 5e, 6e, 7e en 8e getallen op een rijtje zet en de reeksen hier posten? (dus voor de 1e letter zou dat worden: TKWTJMSTDBL...) Dan kunnen we daarin ook naar regelmaat zoeken.

Het is een beetje een kutwerk om dat allemaal met de hand te doen

Acties:

Verwijderd

In public key cryptografie bestaat de sleutel uit twee delen. Een publiek deel, dat iedereen dus mag weten en wat gebruikt wordt om berichten te versleutelen. En een secret deel, wat alleen bekend is bij de ontvangende partij en wat nodig is om berichten te ontsleutelen. Iedereen kan nu dus berichten versturen, maar deze keer WEET je dat en dus moet je andere maatregelen treffen om vertrouwde partijen van vijanden te onderscheiden.

Nuancering/aanvulling: Persoon A heeft 2 keys: KpubA en KprivA. Persoon B kan nu een bericht versturen naar persoon A door het te crypten met KpubA. Dit kan alleen gedecrypt worden door KprivA. Andersom werkt ook: data geencrypt met KprivA is te decrypten met KpubA. Dit lijkt zinloos, maar zo kun je achterhalen dat alleen persoon A de data moet hebben ge-encrypt, immers die is houder van de private key KprivA. Dit laatste kun je gebruiken voor het herkennen van een 'geldige afzender' (wordt gebruikt in certificates en bv ook voor het signen van components).

dinsdag 5 maart 2002 13:24

Acties:

dinsdag 5 maart 2002 13:33

Op dinsdag 05 maart 2002 12:15 schreef mr_obb het volgende:
Kan iemand een programmaatje schrijven dat alle 1e, 3e, 4e, 5e, 6e, 7e en 8e getallen op een rijtje zet en de reeksen hier posten? (dus voor de 1e letter zou dat worden: TKWTJMSTDBL...) Dan kunnen we daarin ook naar regelmaat zoeken.

Het is een beetje een kutwerk om dat allemaal met de hand te doen

Tsjah, hier dan maar............

code:

De eerste:

TKWTJMSTDBL236VZ3MWHKW5A47YELUFVH29KWAQWV42JZGC9V6L9GVXQBJSVVD5G4DMSHY7UDZXXUBYL
ZX2R49RKNLS4E6ETTBQER2UBTSH4QYH8KRRCLM585A4QN9CQLYNB5KCDL6B6GMFWDYQND4VEF5LWBE3S
B2Y5D54WWKH85JKFW4WRR5YND8Y9NNSXNXTLWH4B76B5Z8PD3JCW2B7N9P29VN83P7FPMNWU2GH87JB4
EA9B5JTX2E4NWL9YTZQZWLH7H8N3ZJ7R9CTYUZJT7VQKJZUX493FLMV5MKX2SLN28G94L4QEHGB584HW
MESDSWCQVEGENJ2WESUEWC3JSS72BKPKLF3FBCMVFKD3NHKZVFAGU4MSA87RLGY8VLU6WMDP8SRCKB6K
5T9VFBYLXLS3BV9NQ3PN2V874EUNVUBG2JUECPK4NRUSHFLX5P6GXU7WF3TDPB24CND5DCPPH3AY76HE
NP7T5VQ9CG2NWRYV842K3UN8GZV69WU28UPTVWN54KL4SHCABNKW5GM6U62BDNAJCK23RGZXK6XBTF34
UNUZ2K6A5VXWQL7Q9FWLFQHJQPW4CJ2PYJQL7Y2S7JYX96MV7PVCTGD38SXWG8VJEWZ9NEGPRYJBXH6R
WMGEA5GUJA46WSGLP82FZ62VFGDGWGHCLYNY6TP9TVFNFE3BQ4YQKW7FJN5TQYK9QVL63QHQAGDHELMC
2XVHU54C3XJBHA29JPELFMEV3DCKRHZ95H6NEWMYVQ6D2DZ4AMGHYQVLM7P2VDTAD9U7Z5XVFGJTRAZE
3JAUBUSSDL5LJEFSVQXKNVQ2DHWNKPWUBQA3553MADH5X2P37TF8NSE3B8NEZX9BDXWYRPJTL6U7MZ2R
VGAX2JPQHKWN4332M4CJL7SBVRENU9QRSERPLSQYXJLY5EFQBJVT96B4HSPREDS2H7WCE7U9RLM2C475
4BPGM3C6EKY8MXTR4Y869B63ZTKPH4LYZ984LTB

De derde:

22X22G22XXF2RR2RRGXF2XFR6XQXFGG2F2G2XRGX2K22S2SG2SFG22FGX2222XF2UXG2FTXGXSFFGX4F
SF229G22XF2ZXSX22XGX22GX22FCGRF2222SFGF2FSBGXGSGFMXXF2SXFSXT2GGXXPGXXJ2XGFFXXXT2
X25FXFPXX2F2F22GX3X22F9XX2YGXX2FXF2FXFQXXTXFT2TXT2TX2XXXGT2G2X2TTXGTGXXG22F2X2XT
X2GXF22F2X8XXFGT22G2XFFXF2X222X2G22YG222X2G222GF5G2GFG2FG2F22FX222GZFHGXF2XF2BFX
GX2X2X2G2X2XX22XX2GXX88222X2X282FG8GX8G2G2X8XF282G82G7G282X2F2222FG8XGX822282X82
F2G2GXVFFF28X2GXG88X222XZXGX2GX222GX442XX2G2FGFFF442FGXXG42X4X2R4XXFX444F447X4FX
X4X2F2GG422XX2W223224GX22424GXG22G422XXFH2FL2FYYXX2XF2GYGY2XXXY2Y22Y22YF2YFX2GYD
GXGY22YYF2FXGFXGGGXFGGF2GYXEY22Y32GFX922X2AFGYG2XY2Y22XY22FX222255AG552A2Y25FFA2
5G25AF2G2AWA522FA22GAA22G25252FAFK5CA2AG22G5G5A5GHRG255G25F2GU2GG2FAAGFGA25F5FGZ
2F2FGF6ZZF25FZ2G2Z5FGG52Z5Z22FZGFFZ555GH2GZ525ZBZG2FSG2FG5Z2252Z5GG5ZFF2G2222ZZ5
Z2ZG5G225FFF25G22GF252G25F55265G5G66FF6G65FFF26652G2525652556FG55F5E2622F6G5G622
226F226GF2553662G462F5252255GGG2252PF2GKF2FFF5GG5222GP52F2P25522F55P55GG2FG2PM5F
75P2GPPP52E2GF22WH2PG5PPP22PFYF3PG2PF25

De vierde:

GXGGR8XGFQGGCGRXPUG2XG2XG2GRGSURFGUXGXNGRGGSXX8TSGGZXS23WSXSSF2XGFNXHG2VFX22X9GG
X2GXG9XXSGXGSGSGGP2SXGGGGXZG6GYFXXX8G9232XGGS7CJGGSD2XEFGGDGX4UGFGBTFGTTV2GGHTHX
5GG2F2GGGXF42TX8GGGXX2GTFKG8TTX2T2GGGWG52GX2XQ2FQTPGGW2TF2GXTTQV22B2LTGAGX6H222G
2XMF22G2G2G2GGGGGXCXGG822E2JX22XFQGG2X2G22TX2X52GHFKG622DX2GXG2GNX8GGGR26X42KG8G
Z2XFXGMV22X888GG8XA8G4E8XX2GNX2XGAX58KE8RXFT8FXX8UXXWGXXXZ2XGXGB8GAGGJF2GXX7XRGX
2GG89PGG2GXJ68Q82G28G8K2G8K44E4XG4S4X2XG4X3XVSG222GX2G2GQ8GF2YGG64F2FQ22CHXG2GK4
422G243VMXG4GXG4LGGXGF44XX4GVGRGD32G4G42GXGGXU3XRYXG2X6G4GGXFYXYKXG6XXX2XG2HGPFG
XYZXGXGX2Y2GYG2US7GGP9KYB2GG3YG2GYCG2GGX2YG27GWY22YEGXF35X2GXDAAAG5XAA525GA72WG5
GY5A5257A5GGG55G2BG85GGA55F5G544GGAGGG2HGAPA4A2WWGG55G2MAA2GXG59RAGGYVYG55FSAGBU
G2ZYX2GNH2ZF95GGZ2ZGR3ZZ8F75595W2XGZZGBGZ9GFGF5G5R5WGNZGA22GZFG5FEX2522Z85ZG555Z
QZ5TKX55FG2GZ6K56E2566VGFEG652G9Y95322BZ5FC22G2S2GC56565TK6652PGF2GG526GGGD2S5G5
6552G62RQ5G6G9UGQGK6G25B6566J3755P52G5YG2PGG2PDWGPPGCGWG9525PF5GQ2GRP26D5G9G3G22
G325DVKGP5G4C2G5GG7G74G85G52FGGG54XGGGD

De vijfde:

RRRRGRFRQG2FFFX2FRR2RRXFRRXU2XRX2FRRRF2RXRFG2SXSXF2SSXS2GGFXX5XSSLSF2XSXH2SSXGX2
2SFFSSFSG2FSWF2SSG25FFXGSF2S2X2FSFFX2SXFXFS2GSX22XGGXSX92FGFTTTT3X2GSTXMTX2TGDFF
GFXXEXTTTT2FXGTTTTTFFXXGTFXTGGFTGTT2T2TGTFGX2FAGFGXTFGTGTUFTXGFFJTTXTGTXFT2F2GG2
GF2GXG22FC2G222X222222222FGF2G2F2X2XX2G22X22G2X222F222XX222FF2GFF222222D22GXF222
24F2F2X2XD8XGGF8CFXF8XFGFF8FG8J828F8GX8X88TFG282X8F8X88FFF8F28XFX2XF88G6FFFX8GF8
X88X8GX282FFGX8G2FCGFXF88AXGXXG4FGX8XB44GFXF2424XTF44X444F4TZGF4XGGXMXPC2FFX4F2G
GY44XX24X4FG4FXXF4F4FXGF42XF44XFFX74X4GX4424F2XFGGYYXYYFXFFGGGFGXYFFFY2YYFYGYYFY
XGX2FYFFXXYY22Y2YYY2Y22G2NYYXGFKXG22YXFFYGXYYFYXYKXXYYQFFFYYYF5GNA2AGRAKF5GGA2FF
AAA5F5A5GFAFAFA2HFFA2FF5AA4AAA2525G5FAAAA5AGAXFG2A52AAAAGG5A25AA252FF222FAC2L2Z5
FZ5255Z5FZGG2FFZGLZ2ZZ85FE5ZF22Z52FGCZZ552F5FE2ZFZZ25252ZZNF5MZFBZ5Z25Z5ZZGZFF2C
FGF5G5FFN252GS6F5266G52FK26G6965G2FF55F6FC256F2F666FGFHFGFGF266GA665FFG62F5662FF
56F6FGZ2266G6FFF665G26FG5FXG5P2FFUF82F25PG255QP2GG5PPFGP2F7FEXFF2PP5VP5PF2PF5PP5
PGXPPF5FYP5FPPPFP5FFPGFF2PPH2P252PFP2PG

De zesde:

FG2FF2JF2RRXX2FFX22RG2GGXF2FR2XFRX2G2GR2FXXFFQG2F2S2BF4SSFXFF2G7X22WS2F22FGN2S2S
FXXGX2GG2SGXF2FFFSSFGX2SFZSXS2SXGGGGS2GXGGXS22GSS22SGGG2S2T222X222T22XFFXGT2TFXE
TX2G2GX22GTXGFGX2X2GGG222X2222M82WFT2TXTF2TGFXX2XFG2XTF22XX2F2XXXFXX2222XW2XFF2X
FG22GFFKXFX22222FF2F222F2X2XFFFG2GF22FFFFF2GFF2AX2XX22FG2GJX422XXF2X2X2F2H2GXX22
2FZ242G2FFCF2FX2FZ2F2GXFXBFX8GXG8XXX8G2FXG2X28GFFXGG2X2UGXFG892XF822222XXUGGG82G
GF2FX82888RX8F228XX2XFXFXF22F244XF2FGXGX2G2X4X4LGX2RB2F2XXF2X4XXG22G2GXX4XG2F24F
2XFFGF42G9X22G2FXXXGX22XNFF2222XX2XFF22GXG4X9YGGY2G2GU2222XY22GFGGXXG3FLG27YFXXX
222FXG2GGFR2YYFY2X2YXYYFYX2XGFXX2FYYF2XSFF2L222FFXFGFV2XX4L2H5FFF2F22FG5G2FAXA2G
22TFGGR2FG522XZA5555F25F5N2D2RAGA2222F52FF525F5AA52AG2F5F2GFA2G2AFA25AAAGH2AFZ2G
5SFZ2G5G5JFZZG52F5FZ52FF52GGGZF2GZ22F222FZ2252F5G28Z2ZFZ2F55F2FG222FFGYF5PFFGGFF
5FG2Z2E52ZGZFF5ZF6PG2F652622G52266G5GG52G26GR555FF552CF5652FFM262C22G5FF622F2F5G
FFGD5F566G22555525GF6FW6FGF222PGLFG5PNP2HFP2GF5PPFFF22P5PA5GF2F5PF2GFF22GP25G5FG
5P5725G2FG252BFG52522P25FFG5P5P2F255PFP

De zevende:

DB6SXXG3GF3RGXJZGX5GRUR22LF22R2LGRFJ42XLW2SXAF2FLXFFF4XXFXGGVGSF2GXGGFCSGGXXSFFF
ZXSF2F683SG22X2RCFX25SSFSGG2XFGG4NW2RXSGS22XPF2X4F6FSH2GLXFXFX2CGFXNG2T22TFHF2GG
FTFTGT2WE2GGTXN2M28C8TFBGGFF49GXEXJ3BG2FAXFTGGFGGX2BTFATFFTFBCGGFT2FXXGTTFGGRXF2
22FF2XFX222RQKFFLMXVH7GAGGVGEXQSF24F2WXY8MXDX22X2FG2BXY2XPX2GSF2GFF242X2GFF2G2GQ
X2GGGD2XB2F2RX842G82Q2GXGGQ8FAFKN2G2F2X72AGG3GTLV22F82XG2GW5RFFGKZ8X7XGFGG62GFXV
8SF82FFPXLGGFDFWXGFZ83G32243K4FF4X422F62YB4GG25X4FXFX4SN2G9GFF4222G4G2FFGG2FVXG2
7FML4VXF2F4TX6FUG24MG4WGFRAXFW44G4FWL5R42KN2GG22FM4ZYFXXYXYFG82X22YGPF9XEXXF72G2
YGY7Y7X2YCX3X32XF2B72XGXXF822XYFFXXVEFYG2XFXFXXEEFC2SFGGGGX3FG752HGFJ2FFXF5F5G59
H5F22AFA5225EGFQFGA2E5AZ2FGFEFG26F3F5DFFE82D22GF52F5CHP25EAP5F6F5295G5G52FGG2T52
Z57GZZ22G55FG2ZF5F2A252DGG29RGVFZG5W295FU55GZGL225FGF58R5WFZ9GA2GFZDBZ5Y2F5JZ2M2
G52ZFZGGGQZ7522GU55BSL56GGKKMFT6F52G66G52GG656FGAV2GSG2GFGS295FFG5DFWF5AZ5635N6B
KF2565F5GEDX2GG65225U9GFC5256F5UG2DFNG5F557FP225F55MF5F2GGFH2GGPGLA22EPFDS5P22HP
2FFF5G252WFG55VC2FG5FF5GUDUFG2HFHFG22PF

De achtste:

XFFXCFRXR2XP2WGG2FFXFF38FGRGXFFGXLXFF4FFGFDEGGFXGDXXGGGF2BSGGS4GFSFSXSGFSGGGF2SX
GGWSFXSFFXSFG8GXX2FGS2F2XSXFFSXSFSSFXFWSSZFFFXFFXSF2QFFSX42HGFFFTTFFTFGGFGXF2G2T
25TCT7FFFFXTMMFFFFFTTDTFTTTXFFTGFGXXFXF2GW2JGTGT2RFFQ2GFXGZXGFT2GGFGFFFFPGX2GN2F
GWX255XGJGFFFXX2XGFGFXXGX2F2GCG2XFX2FGHXGGFFPGFGFX2FXFGRFFGD2XFY2GXFXFFGXG222FXF
FG222FFFGGGGFPXFG8FGFF2H88GM2FGFXF2F2FFGFF82FXFGGFUGFFF8Z8G8XG88GXFGFF8G888FF2AF
ZXXGF28XGX822GXFF2GFFG8GFGFFGF2GQBFGFGFFF4F4XFXG3GLGGFGFF2X4G2DFFF4Y4FGGX294GWXG
FGGXGGFXFGWFF44G4FRF2FF4GGGJXFFX4FGXGFF5FFXF4XFD2FFFXGF7FKU2YFPJFFY2YGGGF8G2XF2F
FFFGLF64GGGFFXGFXFFXFFXUFGFFFFPGYNFXGYZYGVYGXEFGGGGFXGY2YYGFGAG7GFG5FGGGAA92G5NA
FFGGRMGFRRFGFAG5GALFGCKGFGAGFG5F5AFAL5G55GFFFG22FFAFFFGFTF35FAF5FG5Z2F5F6GA5G5FF
JGG5FAFF2GQ25FJ5YGG5FFGG2ZFFZ5G5T5ZFGFFZGFTZ8ZGF4FG5ZFG5FGGTGZ57Z5FGG4GGFGN5ZWGG
2QXF2FZZZ5E5VGF6GFGFFGFM65FFFGFF2FB2AW2FJ65RGJG2G5F6F6G226FGGG526GF66G755EFGFGF6
GGQGZBGF5FFFF22AFFFU5G62G6GFF5FPPGPG5PFPG95PBGFF25G55J2F5PGPGPPW5GFFGGF5P5F3FFG3
F2GGF2FTGFPPFG5PFPPU52P2G5FG5F5PG5PF552

Veel plezier d'rmee

Acties:

dinsdag 5 maart 2002 13:39

Lakse Perfectionist

Bedankt

Hiermee moet het lukken

In de eerste reeks zit in ieder geval geen duidelijke regelmaat.

Acties:

eNaSnI

In de eerste reeks komt de I, O, 0, 1 niet voor (waarschijnlijk komen deze in meer kolommen niet voor)

Wie zoekt, zal vinden http://www.google.com

dinsdag 5 maart 2002 13:46

Acties:

dinsdag 5 maart 2002 13:50

Op dinsdag 05 maart 2002 13:39 schreef eNaSnI het volgende:
In de eerste reeks komt de I, O, 0, 1 niet voor (waarschijnlijk komen deze in meer kolommen niet voor)

FF gecheckt, komen nergens voor .. zijn ook de enige getallen/letters die niet voorkomen in deze reeks.

Acties:

silentsnow

« '-_-' »

Topicstarter

Op dinsdag 05 maart 2002 13:46 schreef Dash2in1 het volgende:

[..]

FF gecheckt, komen nergens voor .. zijn ook de enige getallen/letters die niet voorkomen in deze reeks.

0,1,i,0 komen idd nergens voor.

The trade of the tools
[ me | specs ] Klipsch Promedia Ultra 5.1 + Sennheiser HD-590

dinsdag 5 maart 2002 13:55

Acties:

eNaSnI

Edit: Iedere code bestaat uit minimaal een 2, een G en een F

Valt op dat ieder karakter in een bepaalde serie getallen iedere rij voorkomt (bijvoorbeeld de T in rij 139 t/m 234).

Wie zoekt, zal vinden http://www.google.com

dinsdag 5 maart 2002 14:01

Acties:

dinsdag 5 maart 2002 14:47

Op dinsdag 05 maart 2002 13:55 schreef eNaSnI het volgende:
En van de 2XGF serie zitten er in iedere code minimaal 3.

Lijkt me duidelijk, aangezien de 2, de G en de F in elke rij voorkomen

Acties:

dinsdag 5 maart 2002 15:23

Ik wil best geloven dat het voorspellen van de volgende code in deze reeks erg moeilijk is (daarvoor is 1000 ook wel een beetje weinig) maar dat het bedrijf beweert dat de data "volledig willekeurig" is slaat werkelijk nergens op.

Ik heb de data even door een bekende randomness test gehaald en daar kwam dit uit:

code:

Entropy = 4.272697 bits per byte.

Optimum compression would reduce the size
of this 11988 byte file by 46 percent.

Chi square distribution for 11988 samples is 222893.20, and randomly
would exceed this value 0.01 percent of the times.

Arithmetic mean value of data bytes is 55.3408 (127.5 = random).
Monte Carlo value for Pi is 4.000000000 (error 27.32 percent).
Serial correlation coefficient is 0.138467 (totally uncorrelated = 0.0).

en dit wordt maar iets beter als ik alle '-' en newlines eruit haal:

code:

Entropy = 4.281602 bits per byte.

Optimum compression would reduce the size
of this 7992 byte file by 46 percent.

Chi square distribution for 7992 samples is 152521.79, and randomly
would exceed this value 0.01 percent of the times.

Arithmetic mean value of data bytes is 68.8861 (127.5 = random).
Monte Carlo value for Pi is 4.000000000 (error 27.32 percent).
Serial correlation coefficient is -0.057916 (totally uncorrelated = 0.0).

Voor deze test de betekenis ervan zie hier

He who knows only his own side of the case knows little of that.

Acties:

dinsdag 5 maart 2002 15:42

Lakse Perfectionist

Dat ziet er inderdaad niet best uit. De tweede test geeft aan dat het wel een stuk verbeterd. De Serial Correlation coefficent halveert.

De regelmaat van de tweede letter is blootgelegd, nu de rest nog.

Acties:

dinsdag 5 maart 2002 15:48

Op dinsdag 05 maart 2002 15:23 schreef mr_obb het volgende:
Dat ziet er inderdaad niet best uit. De tweede test geeft aan dat het wel een stuk verbeterd. De Serial Correlation coefficent halveert.

De regelmaat van de tweede letter is blootgelegd, nu de rest nog.

Nou, compleet regelmatig lijkt het niet .. heb je anders een oplossing voor die paar 'onregelmatigheden'?

Acties:

dinsdag 5 maart 2002 16:48

Lakse Perfectionist

Op dinsdag 05 maart 2002 15:42 schreef Dash2in1 het volgende:

[..]

Nou, compleet regelmatig lijkt het niet .. heb je anders een oplossing voor die paar 'onregelmatigheden'?

Daar ben ik nog naar aan het kijken. Ik denk dat ook daar een regelmaat in zit.

De makers van deze reeks kunnen trouwens niet zeggen dat de iedere key volledig onafhankelijk is van de vorige...

Acties:

Verwijderd

Die Chi square distribution kan natuurlijk falen omdat je ascii representaties voert als zijnde de getallen, terwijl het werkelijke getal meer gepacked in bits zit en niet per byte in een zekere range zit. Ok, deze ascii representaties zijn wellicht 1:1 afbeeldingen van de werkelijke getallen, maar daarom hoeft de Chi square distribution test nog niet te werken.

Die compression test bv is al niet valide, ascii packt nu eenmaal erg goed, ongeacht de randomness van de data.

dinsdag 5 maart 2002 17:24

Acties:

dusty

Celebrate Life!

Op dinsdag 05 maart 2002 10:01 schreef kvdveer het volgende:
[..]
disclaimer
Bij de bovenstaande formules is het kraken van de seed met brute-force een eitje. Het lijkt me niet verstandig om die écht toe te gaan passen. In Real Life wordt er echter gebruik gemaakt van veel grotere seeds (sleutels), die niet met brute force te kraken zijn.

*kuch*, Alles is te kraken met brute force, de vraag is alleen hoe lang je er dan over zou doen

Back In Black!
"Je moet haar alleen aan de ketting leggen" - MueR

dinsdag 5 maart 2002 18:42

Acties:

dinsdag 5 maart 2002 19:25

Op dinsdag 05 maart 2002 17:24 schreef dusty het volgende:

[..]

*kuch*, Alles is te kraken met brute force, de vraag is alleen hoe lang je er dan over zou doen

*kuch* Nee.
Zie mijn verhaaltje over one-time-pad crypto eerder in dit draadje.

BTW Otis, ZÉÉR goed punt heb je daar. Vooral het feit dat maar een paar ASCI tekens gebruikt worden maakt de resultaten op z'n minst onbetrouwbaar. Ik ben de tests opnieuw aan het doen op de bit representatie van de data en de eerste resultaten wijzen uit dat het idd veel uitmaakt. (Tot nu toe nog niet voor de Chi-kwadraat test, die blijft op 0,01% steken)

He who knows only his own side of the case knows little of that.

Acties:

dinsdag 5 maart 2002 19:40

Op dinsdag 05 maart 2002 18:42 schreef RickN het volgende:

[..]

*kuch* Nee.
Zie mijn verhaaltje over one-time-pad crypto eerder in dit draadje.

BTW Otis, ZÉÉR goed punt heb je daar. Vooral het feit dat maar een paar ASCI tekens gebruikt worden maakt de resultaten op z'n minst onbetrouwbaar. Ik ben de tests opnieuw aan het doen op de bit representatie van de data en de eerste resultaten wijzen uit dat het idd veel uitmaakt. (Tot nu toe nog niet voor de Chi-kwadraat test, die blijft op 0,01% steken)

Hmm, vraag me af: hoe doe je dit?

Acties:

dinsdag 5 maart 2002 20:14

Op dinsdag 05 maart 2002 19:25 schreef Dash2in1 het volgende:

[..]

Hmm, vraag me af: hoe doe je dit?

Met deze tool (heb ik eerder in dit draadje ook al gepost hoor.) De tool heeft een optie om de data als bytes of als bits te interpreteren. Punt is nu alleen dat ik hier ff geen programmeer omgeving heb geïnstalleerd en ik dus de enters niet uit de data kan halen

.

De resultaten met data geïnterpreteerd als bits en alle '-' verwijderd zijn (maar dus nog incl newlines):

code:

Entropy = 0.968816 bits per bit.

Optimum compression would reduce the size
of this 79936 bit file by 3 percent.

Chi square distribution for 79936 samples is 3430.66, and randomly
would exceed this value 0.01 percent of the times.

Arithmetic mean value of data bits is 0.3964 (0.5 = random).
Monte Carlo value for Pi is 4.000000000 (error 27.32 percent).
Serial correlation coefficient is -0.150456 (totally uncorrelated = 0.0).

Bit interpretatie heeft dus vooral veel invloed gehad op entropie, elke bit heeft nu bijna 1 bit informatie waarde, terwijl dit bij byte interpretatie veeel minder dan een byte was. En ook de compressbaarheid is enorm afgenomen, maar deze waarde hangt dan ook af van de entropie. De overige test zijn niet veel beter geworden. Met name de Chi-kwadraat test faalt nog steeds ontiegelijk.

Aan deze resultaten kun je b.v. zien dat de bit representatie van de data voor ruim 60% uit enen nullen bestaat en dat kun je natuurlijk niet erg random noemen als je kijkt naar een reeks van bijna 80 duizend bits. Let wel, dit kan natuurlijk komen door de overbodige newlines waarmee ik heb getest. Iemand zin om me de data te sturen zonder '-' en newlines???

He who knows only his own side of the case knows little of that.

Acties:

dinsdag 5 maart 2002 20:23

you've got mail

Acties:

dinsdag 5 maart 2002 20:25

Met dank aan Dash2in1 voor de data:

code:

Entropy = 0.980118 bits per bit.

Optimum compression would reduce the size
of this 64080 bit file by 1 percent.

Chi square distribution for 64080 samples is 1758.07, and randomly
would exceed this value 0.01 percent of the times.

Arithmetic mean value of data bits is 0.4172 (0.5 = random).
Monte Carlo value for Pi is 4.000000000 (error 27.32 percent).
Serial correlation coefficient is -0.157859 (totally uncorrelated = 0.0).

De entropie is er door het verwijderen van de newlines dus nog wat op vooruit gegaan. Daardoor is de compressbaarheid nog iets lager geworden. Maar volgens de Chi-kwadraat test is deze data nog steeds alles behalve random. Ook gemiddelde van de bit representatie (gemiddelde van de enen en nullen) toont nog steeds aan dat er teveel nullen in de de data zitten.

He who knows only his own side of the case knows little of that.

Acties:

dinsdag 5 maart 2002 21:00

weet je ook de kans dat die toeval is? Kan natuurlijk ook gewoon daar aan liggen.. alhoewel er op zich wel aardig wat bits staan.

Acties:

dinsdag 5 maart 2002 22:24

We hebben dus al een aantal feiten.
1. van een rij van 8 tekens is de 2e steeds 3 x hetzelfde
2. de F komt in elke code voor
(3. mijn idee -> de G komt denk ik, nog niet gecontroleerd, ook in iedere code terug.)

edit:

4. de G komt ook in iedere regel een keer voor
(ik heb snel ff een proggie geschreven om het te checken, dus ik kan in m'n haast wat fout gedaan hebben)

[EDIT - 2]
5. (wederom volgens dat proggie) de 2 komt ook in elke regel voor
[/EDIT - 2]
We gaan dat kreng nog krakuh

One ring to rule them all, one ring to find them, one ring to bring them all, and in darkness bind them...

Acties:

dinsdag 5 maart 2002 23:10

Op dinsdag 05 maart 2002 20:25 schreef Dash2in1 het volgende:
weet je ook de kans dat die toeval is? Kan natuurlijk ook gewoon daar aan liggen.. alhoewel er op zich wel aardig wat bits staan.

Ik snap je vraag niet.

Die monte carlo methode om Pi te berekenen beschouwd de data als coördinaten in een vierkant van 2 bij 2 rond de oorsprong. Ik vind het zo apart dat er precies 4 uitkomt telkens. Misschien zit er gewoon een bug in de methode, maar ik ga morgen voor de fun ff een plotje maken van al die punten in dat vlak, misschien dat daar nog iets vreemds uitkomt.

He who knows only his own side of the case knows little of that.

Acties:

woensdag 6 maart 2002 00:05

Op dinsdag 05 maart 2002 22:24 schreef RickN het volgende:
Ik snap je vraag niet.

Bedoel, dat het in principe ook toeval zou kunnen zijn dat het zo onwillekeurig lijkt...of is de kans daarop statistisch echt veeeeeeeeeeeel te klein?!

Acties:

woensdag 6 maart 2002 08:28

Nou, laten we eens rekenen:

Als het een echte random sequence betreft volgt het aantal enen X een binomiale verdeling met n=64000 en p=1/2. De verwachtingswaarde is dan E(X)=32000 en de variantie Var(X)=16000. De centrale limiet stelling zegt ons dat deze verdeling ongeveer een normale verdeling zal volgen dus X~N(32000,16000)

We willen nu de volgende kans uitrekenen:

P(X<=26700 v X>=37300) (deze waarden volgen uit het geobeserveerde percentage enen)
={symetrie}
2*P(X>=37300)
={normaliseren}
2*P((X-32000)/126 >= (37300-32000)/126)
={standaard N(0,1) verdeling}
2*(1 - Phi(42))
~{Phi(42) is ongeveer 0.999999... dus ongeveer 1}
0

Dus lijkt me geen toeval

Vuistregeltje:
De kans dat een geobserveerde waarde maximaal 1 x de standaarddeviatie afwijkt van de verwachtings waarde is ongeveer 95%. Als deze sequence echt random was zou er 95% kans zijn dat het aantal enen tussen 31875 en 32125 ligt. Er zijn echter maar ongeveer 26700 enen en de kans daarop is in een echte random sequence verwaarloosbaar.
Statistiek....you gotta love it...

He who knows only his own side of the case knows little of that.

Acties:

woensdag 6 maart 2002 10:28

Devver

Pixelated

Nog een leuk stukje over versleuteling

Intentionally left blank

Acties:

Verwijderd

in de tweakers.net posting over deze bodacions meldden ze nog dat indien je de wiskunde erachter begreep je NOG de volgende getallen niet kon voorspellen. Lijkt me dan niet zozeer met wiskunde te maken te hebben maar met een externe random generator (op basis van celdeling?)

Ook de vertaling getallen -> ascii waarden is niet bekend of wel?

woensdag 6 maart 2002 11:08

Acties:

woensdag 6 maart 2002 11:25

Vraag me ook af wat die 2 streepjes er in doen eigenlijk.

Acties:

woensdag 6 maart 2002 13:14

En je kan je ook afvragen of er wel naar de 1e bit (128) wordt gekeken .. die is nl altijd 0(nul).

Acties:

woensdag 6 maart 2002 13:38

Devver

Pixelated

Ik denk dat je helemaal niet naar bits moet gaan kijken; althans niet in de zin van dat je naar de bit-presentatie van elke individuele letter/getal moet gaan kijken.
Er komen immers maar 32 verschillende letters/getallen voor in de code; om elke letter/getal in een bit-waarde te kunnen schrijven heb je aan 5 bits genoeg.

Intentionally left blank

Acties:

woensdag 6 maart 2002 13:45

Ik heb nu twee grafieken van de data geïnterpreteerd als punten in de range (0..1,0..1). Als de data volledig random zou zijn zouden de punten uniform verdeeld moeten zijn over dit vlak. Als dat zo zou zijn zou je ook een nauwkeurige schatting kunnen maken van Pi, zoals in de randomness test gebeurt. Maar wat blijkt, de data is verre van random. Dit zie je ook heel duidelijk in de grafieken. Ik zit nu op m'n stage en kan vanuit hier om een of andere reden niks op m'n webspace fpt-en. Ik kan ze wel naar iemand mailen, die kan ze dan posten... roept u maar. Zoals crisp ook al opmerkte zitten we hier te kijken naar een zeer redundante representatie van de data. De slechte randomness eigenschap zal dus wel schijn zijn. Als de data binair gerepresenteerd zou worden met voor elke verschillend element maar 5 bits zouden we denk ik een heel ander beeld krijgen.

He who knows only his own side of the case knows little of that.

Acties:

Verwijderd

Mail maar ff naar fladder@paranoid.nl, zet ik um wel ff op me webspace

woensdag 6 maart 2002 13:54

Acties:

Verwijderd

okdan, de grafiekjes van RickN

De punten geplot in de range (0..1,0..1), samen met de cirkel rond de oorsprong met straal 1.

http://130.89.160.56/bodaicons/punten.bmp

een uitvergroting van het gedeelte waar de punten geconcentreert zijn.

http://130.89.160.56/bodaicons/pointszoom.bmp

[edit]Deze images vroegen om een wachtwoord.. Niet echt prettig om deze thread dan te openen

woensdag 6 maart 2002 15:18

Acties:

woensdag 6 maart 2002 16:09

Z.O.Z.

Wat mij opvalt is dat er maar 32 verschillende tekens worden gebruikt... 32 permutaties == 5 bits.

5x6 = 30 bits

Ieder getal is dus 40 bits.
We hebben dus al een 'regelmaat' ontdekt in bit 6 t/m 10

Misschien dat we een regelmaat kunnen ontdekken in andere bitreeksen?

Localhost, sweet localhost

Acties:

woensdag 6 maart 2002 16:28

Devver

Pixelated

Tabelletje met hoe vaak een cijfer/letter in totaal voorkomt, en in welke positie:

code:

figure occurance position 1 position 2 position 3 position 4 position 5 position 6 position 7 position 8 
  2  1190    38    33     292     141     167     274     163      82 
  3    99    31    30       5      13       1       1      13       5 
  4   204    38    30      21      28      30      13      26      18 
  5   472    32    33      76      72      60      69      72      58 
  6   176    28    30      19      26      27      13      19      14 
  7    93    28    30       3      10       2       3      12       5 
  8   185    25    30      17      30      32      15      16      20 
  9    96    31    30       3      14       2       3      10       3 
  A   175    21    30      17      22      35      17      17      16 
  B   103    38    30       3       9       2       4      12       5 
  C    92    26    30       2       9       8       3      10       4 
  D    95    30    30       1      10       3       2      13       6 
  E   104    35    33       3       9       4       2      14       4 
  F  1084    26    30     134      42     201     191     166     294 
  G  1097    30    33     146     257     115     139     156     221 
  H   101    33    33       5       9       4       4      10       3 
  J    93    32    36       1       5       2       3       5       9 
  K    96    31    33       3      14       4       1       8       2 
  L    99    40    30       1       2       3       5      13       5 
  M    81    26    30       2       4       3       2       9       5 
  N    95    39    30       0       6       4       4       8       4 
  P   178    30    30      18      16      29      18      12      25 
  Q    94    33    30       2      12       3       1       7       6 
  R   138    25    33       9      15      19      12      15      10 
  S   184    30    33      12      19      27      21      22      20 
  T   185    28    36      14      19      36      12      18      22 
  U    90    30    30       2       9       3       3       8       5 
  V   100    41    33       1      10       1       1      11       2 
  W   114    41    30       3      12       1       4      13      10 
  X   715    28    30     138     113     110     126      87      83 
  Y   181    31    30      24      20      35      14      14      13 
  Z   183    24    30      22      22      26      19      20      20

Intentionally left blank

Acties:

woensdag 6 maart 2002 17:22

Z.O.Z.

Op woensdag 06 maart 2002 16:09 schreef crisp het volgende:
Tabelletje met hoe vaak een cijfer/letter in totaal voorkomt, en in welke positie:
code:
1
Een hele grote tabel

Het is dus duidelijk dat dit niet equal-distrubuted peudo-random is.

Localhost, sweet localhost

Acties:

woensdag 6 maart 2002 17:42

Z.O.Z.

Wat ook wel grappig is, om rijen tegen elkaar uit te zetten...
Rij 1 vs rij 2 levert een heel goed gespreide grafiek op, maar dat is tot nu toe de enige goed gespreide grafiek die ik heb gevonden.
(idee: geef alle cijfers en letters een waarde, en gebruik de waardes van de ene rij voor de x-as, en de waarde van de tweede rij voor de Y as.

Localhost, sweet localhost

Acties:

Grum

Op woensdag 06 maart 2002 00:05 schreef RickN het volgende:
Vuistregeltje:
De kans dat een geobserveerde waarde maximaal 1 x de standaarddeviatie afwijkt van de verwachtings waarde is ongeveer 95%.

Was dit niet 2 SD

woensdag 6 maart 2002 17:56

Acties:

silentsnow

« '-_-' »

Topicstarter

Ask Us For Help
If you feel you're on to something, but are not sure, email Bodacion Technologies for help. If you're on the right track, we may give you a clue.

Hebben we al iets concreets?? Misschien kunnen we dat naar ze mailen, zodat Bodacion een "clue" kan geven

The trade of the tools
[ me | specs ] Klipsch Promedia Ultra 5.1 + Sennheiser HD-590

woensdag 6 maart 2002 18:11

Acties:

woensdag 6 maart 2002 21:36

Op woensdag 06 maart 2002 17:42 schreef Grum het volgende:

[..]

Was dit niet 2 SD

IIRC was de kans op een afwijking van maximaal 2*SD (naar beide kanten) 68%

He who knows only his own side of the case knows little of that.

Acties:

woensdag 6 maart 2002 22:25

Devver

Pixelated

random is random, en 999 getallen is echt te weinig om iets over de spreiding te zeggen. Voor hetzelfde geld hebben ze gewoon een rij van 999 gegenereerde codes gepakt waarbinnen toevallig de spreiding een beetje scheef ligt.
Als ik een oneindige rij getallen genereer, volledig random, van 0 t/m 9, dan is de kans dat daarbinnen een reeks van 1000 2-en voorkomt 100%. Dat wil niet zeggen dat het eerstvolgende getal in die reeks ook een 2 is, maar het kan wel, want de kans dat er in die rij een reeks van 1001 2-en voorkomt is ook 100%, net als de kans dat er een reeks van 1.000.000 5-en in zit.

Toch is een reeks gegenereerde getallen nooit volledig random, mits je alle factoren kent. Rekenkundig is deze code in elk geval al niet op te lossen omdat er een aantal dingen niet bekent zijn:

In de eerste plaats weten we niet of het aantal tekens inderdaad beperkt is tot 32.
In de tweede plaats weten we niet hoe de tekens rekenkundig ten opzichte van elkaar in verhouding staan:
In het decimale stelsel kunnen we elk reeel getal maken door maar genoeg eenheden bij elkaar op te tellen. Als eenheid hebben we '1' gekozen. 2 eenheden bij elkaar opgeteld noemen we '2' etcetera.
Maar wat is in deze context de betekenis van 'M' in deze code. En hoe verhoudt 'M' zich tot 'F' en tot '3'?

1 ding is zeker: als ik PI in een 32-tallig stelsel uit zou schrijven kom ik vanzelf deze reeks Bodacions tegen

Intentionally left blank

Acties:

woensdag 6 maart 2002 23:47

Zoals dus duidelijk te zien is werken ze in positie 2 steeds met groepen van 3. En dat er dan een keer 6 achter elkaar komen is een toevallige bijkomstigheid. De meeste komen allemaal 30 x voor, dus 10 groepjes van 3.

edit:

de 0 en de 1 doen niet mee.... zijn ze niet met een octaal stelsel aan het spelen? Als ze dan de laatste 2 weghalen valt dat op, maar de eerste 2 ... dan houd je ook 8 tekens over, en het valt niet zo op.

Was zomaar ff een ingeving

One ring to rule them all, one ring to find them, one ring to bring them all, and in darkness bind them...

Acties:

donderdag 7 maart 2002 08:25

Op woensdag 06 maart 2002 21:36 schreef crisp het volgende:
[..]
1 ding is zeker: als ik PI in een 32-tallig stelsel uit zou schrijven kom ik vanzelf deze reeks Bodacions tegen

offtopic:
O jee, da's wel een hele gevaarlijke uitspraak die je daar doet. Intuïtief zou je misschien wel zeggen dat het zo is, maar er is wiskundig gezien geen reden dat het ook zo [b]moet[b] zijn.

Overigens heb je verder helemaal gelijk hoor, deze puzzel oplossen daar is gewoon geen beginnen aan...

He who knows only his own side of the case knows little of that.

Acties:

donderdag 7 maart 2002 11:43

Devver

Pixelated

Op woensdag 06 maart 2002 23:47 schreef RickN het volgende:

[..]

offtopic:
O jee, da's wel een hele gevaarlijke uitspraak die je daar doet. Intuïtief zou je misschien wel zeggen dat het zo is, maar er is wiskundig gezien geen reden dat het ook zo [b]moet[b] zijn.

Overigens heb je verder helemaal gelijk hoor, deze puzzel oplossen daar is gewoon geen beginnen aan...

Ik meen ooit gelezen te hebben dat PI geen repeterende reeksen bevat, en dat vanuit het ongerijmde daarom bewezen kon worden dat elke willekeurige reeks in PI voor moest komen. Ik weet alleen niet meer zeker of het bewijs ook geleverd werd. In elk geval is het tegendeel nog niet bewezen.
Stel dat er een reeks getallen zou zien die niet in PI voorkomt. Je zou je dan af kunnen vragen of er meer van dat soort reeksen zijn, en is de verzameling van reeksen die niet in PI voorkomen eindig of oneindig?
Als we stellen dat PI oneindig veel getallen bevat die geen repeterende reeksen heeft, dan betekend dat in elk geval dat de verzameling reeksen die in PI voorkomen oneindig is.
Maar is die verzameling reeksen gelijk aan, of een deelverzameling van de verzameling van alle reeksen?

Misschien leuker om deze stelling te bewijzen?

Intentionally left blank

Acties:

donderdag 7 maart 2002 12:34

Een eindige reeks kan best meerdere keren in Pi voorkomen, dat is heel iets anders dan dat Pi een niet-repeterende reeks is.

Dit is een bewijs dat er een oneindige niet-repeterende reeks cijfers met een uniforme verdeling van de cijfers over de reeks (net als Pi) kan zijn waarin niet elke eindige reeks cijfers voorkomt:

Stel elke oneindige niet repeterende reeks cijfers met een uniforme verdeling van de cijfers over de reeks bevat elke eindige reeks cijfers.
Uit deze reeks verwijder je alle voorkomens van de eindige reeks 0123456789. Het is duidelijk dat de reeks nu nog steeds oneindig en niet-repeterend is. Verder is de verdeling van cijfers in de reeks niet aangetast, omdat er van elk cijfer evenveel voorkomens zijn verwijderd. We hebben nu dus een reeks die oneindig en niet-repeterend is met een uniforme verdeling van de cijfers over de reeks, maar waarin de eindige reeks 0123456789 niet voorkomt.

Dit is een tegenspraak, dus er zijn oneindige niet repeterende reeksen cijfers met een uniforme verdeling van de cijfers over de reeks die niet elke eindige reeks cijfers bevatten.

He who knows only his own side of the case knows little of that.

Acties:

donderdag 7 maart 2002 20:32

Devver

Pixelated

Op donderdag 07 maart 2002 11:43 schreef RickN het volgende:
Een eindige reeks kan best meerdere keren in Pi voorkomen, dat is heel iets anders dan dat Pi een niet-repeterende reeks is.

Dit is een bewijs dat er een oneindige niet-repeterende reeks cijfers met een uniforme verdeling van de cijfers over de reeks (net als Pi) kan zijn waarin niet elke eindige reeks cijfers voorkomt:

Stel elke oneindige niet repeterende reeks cijfers met een uniforme verdeling van de cijfers over de reeks bevat elke eindige reeks cijfers.
Uit deze reeks verwijder je alle voorkomens van de eindige reeks 0123456789. Het is duidelijk dat de reeks nu nog steeds oneindig en niet-repeterend is. Verder is de verdeling van cijfers in de reeks niet aangetast, omdat er van elk cijfer evenveel voorkomens zijn verwijderd. We hebben nu dus een reeks die oneindig en niet-repeterend is met een uniforme verdeling van de cijfers over de reeks, maar waarin de eindige reeks 0123456789 niet voorkomt.

Dit is een tegenspraak, dus er zijn oneindige niet repeterende reeksen cijfers met een uniforme verdeling van de cijfers over de reeks die niet elke eindige reeks cijfers bevatten.

Bravo! Ik ben overtuigd

Intentionally left blank

Acties:

donderdag 7 maart 2002 20:39

Vermoedelijk zit er in de 2e kolom een regelmaat in. Ik ben nu even aan het onderzoeken of ik er een regelmaat in kan vinden en ik ga deze even controleren, misschien dat ik dan zelfs al het teken kan voorspellen wat in reeks# 1000 op de 2e positie komt te staan.
Nog even geduld, ik heb goede hoop

One ring to rule them all, one ring to find them, one ring to bring them all, and in darkness bind them...

Acties:

Verwijderd

Ik krijg op deze page nu een inlogschermpje. Volgens mij zijn wat grafiekjes achter een vuurmuurtje verdwenen

donderdag 7 maart 2002 20:56

Acties:

Verwijderd

Ze waren vanmiddag ineens pleite, denk dat een modje het berichtje had gewijzigd want ik mocht er niet meer bij. Dus had ik de beveiliging van die webserver maar weer aangezet aangezien ik die web had gehaald voor die plaatjes.

Die beveiliging kan nu nie meer weg, zal es kijken of ik die erdoor kan laten met een AliasMatch ofzo

edit:

gefixed, een extra vhost op het ip, werkt ook prima

donderdag 7 maart 2002 21:53

Acties: