Merkwaardige stelling van iemand die de wiskunde achter encryptie niet kent. Statistisch klopt natuurlijk dat de helft van de bits de oude waarde heeft, maar die zijn bij de symmetrische algoritmes zoals AES al gepermuteerd in de 128 bit reeks waarin ze verwerkt worden, en vervolgens in de modus (bv GCM) nog eens. Niemand is in staat "de helft" te bepalen - dat is nu precies de bedoeling van goede encryptie.

Leuke stellingen met een hoog waarheidsgehalte. Maar hoe kom je erachter, welke bits zijn veranderd?
Woopie

Conclusie : je hoeft alleen maar precies te weten exact welke bits 'fout' staan om ze te kunnen corrigeren. Of omgekeerd, exact weten welke bits nog wel goed staan, en de rest omdraaien.

Stelling 1.
Door groei of krimp tijdens compressie/encryptie veranderd het aantal bits. Hoe kan je nog van een 1-1 relatie in bits spreken

Stelling 2.
Stel de omvang blijft gelijk en de relatie is echt 1-1 dan zal als het goed is die verdeling benaderd worden. Nee alsjeblieft niet exact gelijk dat is nu net onwaarschijnlijk. Je weet niet en mag niet weten wat voor elk bit de waarde zou moeten zijn.
Random iets proberen terug te zetten is een statistisch kansloze missie

De ideale encryptie een uniek otp van oneindige lengte. https://nl.wikipedia.org/wiki/One-time_pad

Euhm zo werkt het totaal niet geloof ik ;)

Je weet immers niet welke bits goed of fout zijn, of wel dan?

Een 1 of een 0 heeft op zichzelf geen betekenis. Stel je leest ze in reeksen van 8. Dan heb je met 8 1en en 0en al 265 mogelijke combinaties. Wat is dan de juiste?

Laat ik het anders zeggen:

Stelling 3: goede versleuteling van een digitaal bestand bestaat eruit dat je ongeveer de helft van de bits in dat bestand van waarde wijzigt (0->1 of 1->0).

Stelling 4: na goede versleuteling is ongeveer de helft van een digitaal bestand gewijzigd.

Stelling 5: Als je het bericht ontsleuteld hebt, dan weet je welke bits fout stonden

Kun je ons even een 16bits voorbeeld geven ;-)

Het is bekend dat de beste versleuteling (en onkraakbaar) bestaat uit een XOR van het bestand met een bestand wat
alleen digitale ruis bevat (random getallen). Het resulterende bestand is alleen door opnieuw een XOR met hetzelfde
bestand weer terug te krijgen. De reden dat deze perfecte encryptie maar beperkt inzetbaar is, is dat je het ruisbestand
maar 1 keer mag gebruiken en dat zowel de verzender als de ontvanger er over moeten beschikken. Het probleem van
het veilig overbrengen van de content wordt daardoor vervangen door het probleem van het veilig overbrengen van het
XOR bestand. Deze methode wordt "one-time pad" genoemd. Als je bijvoorbeeld een spion in het buitenland hebt dan
kun je die een boek meegeven wat als one-time pad gebruikt wordt en de berichten zijn dan onmogelijk te ontsleutelen
voor meeluisteraard. Echter, wordt hetzelfde pad gebruikt voor verschillende berichten dan is het vrij eenvoudig om de
encryptie te kraken. Daar ging het historisch dan ook meestal op fout.

Het is ongeveer de definitie van (of eis aan) goede encryptie dat de output 'unbiased' is - oftewel, elk symbool (0 of 1 in een binair alfabet) is even waarschijnlijk - en niet van random te onderscheiden .

En er mag geen (vindbare/herleidbare) relatie zijn tussen in de input en de output .

Daaruit volgen je stellingen of opmerkingen - je krijgt alleen significant meer of minder bitflips als de input en output vrijwel identiek, of juist vrijwel spiegelbeeldig zijn.

Ik zie alleen niet echt wat je nu wilt zeggen - je vraagtitel suggereert dat je denkt dat je hiermee iets ontdekt hebt over het kraken van encryptie - dat is dus echt niet zo .

Ander voorbeeld : ik heb een geheim bericht . Alle bits zijn 0 , behalve op een aantal plekken.
tsja, als je wist op welke plekken de bits niet nul zijn, weet je het bericht inderdaad. Maar zolang je niet weet op welke plaats de enen moeten komen, weet je nog niks.

Je multiple choice examen : alle antwoorden zijn 'A' , behalve waar ze B of C of D zijn . Ik heb je hiermee echt niks voorgezegd.

Tuurlijk!

Stel je wilt de eerste twee letters van "Anoniem" versleutelen. De ASCII [1] representatie daarvan is decimaal 65 voor de letter "A" en 110 voor de letter "n", hexadecimaal dus 0x41 en 0x6E, binair dus 0100 0001 en 0110 1110.

Laten we voor de versleuteling het (naar verluidt onkraakbare) one-time pad algoritme gebruiken. Als random number generator gebruiken we ook een bekende, namelijk [2]; deze genereert volstrekt random getallen, in ons voorbeeld 9 en 9, hexadecimaal dus 0x9 en 0x9, binair dus 0000 1001 en 0000 1001.


Decryptie, opnieuw XOR met dezelfde sleutel:


[1] https://en.wikipedia.org/wiki/ASCII
[2] http://dilbert.com/strip/2001-10-25

Kijk - nou komen we ergens! Dus als we voortaan net zoals bij het hacker bit (https://tools.ietf.org/html/rfc3514) een soort cracker-bit plaatsen dat aangeeft welke bits er geflipped zijn en welke niet, dan hoe je ook je wachtwoorden niet meer te onthouden maar kan de NSA nog steeds niet bij je data...

Het klopt dat de informatie in een ander vorm behouden blijft, zie link hieronder bij het pinguin plaatje.
Daar zijn de modes of operation ook voor bedacht zodat er nog eens een flinke obfuscatie stap overheen gaat.
Echter of het altijd 50-50 is dat betwijfel ik misschien bij een oneindig grote dataset, bij een kleine dataset kun je zo voorbeelden bedenken dat het niet op gaat.
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

Dank voor alle reacties!

Jammer dan niemand mijn stellingen echt heeft aangevochten, want stelling 1 vertoont overeenkomsten met de stelling achter de vraag "waarom worden door een spiegel links en rechts verwisseld, maar boven en onder niet?" [1].

Het is correct dat ongeveer de helft van de bits in een bestand, na goede versleuteling, dezelfde waarde heeft als vóór versleuteling. Maar dat wil niet zeggen dat die bits niet "versleuteld" zijn!

Dit kun je aantonen aan de hand van een bestand met een lengte van 1 bit dat je versleutelt. Na perfecte versleuteling is de kans 50% dat het versleutelde bit dezelfde waarde heeft als het oorspronkelijke, onversleutelde, bit. Ongeacht of de waarde van het bit tijdens versleutelen gelijk gebleven is of niet: de essentie is dat je, na goede versleuteling, niet weet of een bit gewijzigd is of niet.

Degenen die hierboven suggereerden dat je, na versleuteling, niet weet welke bits dezelfde waarde hebben behouden en welke juist niet, zaten in de goede richting. Maar toch is dat, denk ik, niet helemaal de juiste verklaring. Immers, in het geval van een bestand met een lengte van 1 bit gaat dat niet op (er is immers maar 1 bit).

Zelf heb ik lang gedacht dat met "versleutelen" bedoeld werd "onleesbaar maken", maar dat is onjuist (net zo min als je een bit kunt "wissen", kun je een bit ook niet onleesbaar maken; je kunt het slechts wijzigen of zo laten).

Nu spreekt een bit misschien niet erg tot de verbeelding, laten we bytes nemen. Bijv. in een sleutel voor een one-time-pad kunnen bytes met de waarde 0 voorkomen. Als dat gebeurt, zal een ASCII letter die met zo'n 0-byte wordt versleuteld (XOR, eXclusive OR) ongewijzigd in de output terechtkomen. Die letter is voor ons mensen gewoon leesbaar, maar strikt genomen is hij wel versleuteld als we niet weten dat de, voor die letter, gebruikte sleutelbyte de waarde 0 heeft.

Zelfs het met "military grade" AES versleutelde plaatje van een penguin [2] is, strikt genomen, gewoon versleuteld (mocht je hier toch een penguin in herkennen, dan betekent dit helaas niet dat je een bijzondere gave hebt ;-). Het effect dat je ziet is vergelijkbaar wat je zou zien bij een one-time-pad met een repeterende reeks bytes (van vaste lengte) als sleutel.

[1] Een spiegel verwisselt links en rechts niet. Dit is, ten slotte, het /dev/null forum ;-)
[2] https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#/media/File:Tux_ecb.jpg (met dank aan Anomiem van vandaag 10:31)

werkt perfect bij een bestand van 2 bits

Versleuteling is ook niet op bit-niveau... nog afgezien dat een bit statistisch gezien maar 50% kans heeft om gewijzigd te moeten worden vanwege het maximum van 2 waarden die het kan hebben... die eigenschap maakt de eerste stelling al waar. je moet in encryptievormen altijd rekening houden met het type data wat je versleuteld, ook conform het voorbeeld met het pinguin-plaatje. Waarom kijken we in deze stellingen dan naar de bits?

Dat is het m.i. wel (bij block ciphers worden groepjes bits door elkaar gehusseld en bij stream ciphers en one-time-pads vindt bit-wise XOR plaats). Waarom denk jij van niet?

Zoals ik gisteravond schreef: de essentie is dat je de onversleutelde waarde van een versleutelde bit niet kent (tenzij je de decryptiesleutel ook kent natuurlijk).

Ik zou niet weten waarom. De versleuteling van de harde schijf in de PC waar ik dit op tik past zich echt niet dynamisch aan aan het "type data". Ook gebruikt security.nl niet ineens een ander algoritme als jouw browser via https een plaatje, filmpje, geluidsfragment etc. i.p.v. tekst ophaalt.

Het penguin plaatje wordt gebruikt om te laten zien waarom AES versleuteling volgens de ECB (Electronic CodeBook) methode, bij bestanden goter dan 128 bits (de AES blokgrootte), ondeugdelijk is. Maar dat probleem bestaat echt niet alleen bij plaatjes; uitgangspunt is dat je ECB nooit moet gebruiken.

Mocht je Duits kunnen lezen, dan kan ik je [1] aanraden (door Jürgen Schmidt, 17.06.2016).

[1] https://www.heise.de/security/artikel/Kryptographie-in-der-IT-Empfehlungen-zu-Verschluesselung-und-Verfahren-3221002.html?artikelseite=3

Even een simpele versleuteling als voorbeeld één opschuiven dus A wordt B (één optellen)

A Binair = 1000001
B Binair = 1000010

Twee bits veranderd en vijf zijn er gelijk gebleven.

Iets lastiger base 64 A wordt QQ==:
A binair = 1000001
QQ== = 1010001 1010001 0111101 0111101

Er zijn 21 bits bijgekomen en van het eerste ascii karakter is 1 Bit veranderd

Je weet dus niet hoeveel er veranderd bij het gebruik van een versleuteling algoritme.

Stelling de helft veranderd is onjuist, heeft te maken met je gevoel en het omgaan met binaire getallen.

No-oS

Ik snap echt niet waar deze hele post op slaat om eerlijk te zijn.
Zelfs met de uitleg later door Erik zelf snap ik nog steeds het doel niet van deze hele thread.

- iets om over na te denken en wellicht reageren op een regenachtige zondagmiddag (en evt. daarna)
- een stukje awareness kweken (ook bij mezelf, klopt het wel wat ik denk?) over wat versleuteling -op bitniveau- doet

Erik schreef niet voor niets 'goede versleuteling' .

Letters opschuiven, of redundantie toevoegen (base 64 = groepen van 3 bytes schrijven als 4 karakters printable ascii) zijn dat niet . Want je blijft de statistiek van oorspronkelijke plaintext zien .

Zoals ik schreef (18:41) - de gecrypte output is unbiased - elk symbool is even waarschijnlijk . [en er is ook geen vindbare correlatie tussen de symbolen ] .

Je stellingen zijn irrelevant in hoe encryptie nu werkt. Dus zou niet weten hoe het awareness moet kweken.

Ik betwijfel of het optimaal is wanneer altijd precies de helft van de bits is gewijzigd.
Goede encryptie zit hem er juist in dat je niet kunt voorspellen welke bits er zijn gewijzigd.
In een lange tekst is het niet erg dat een letter A toevallig een enkele keer na encryptie nog steeds een letter A blijft.
Dat komt omdat men helemaal niet weet dat die letter A in die lange tekst ook werkelijk een letter A is.

Ik heb vanavond "aardappelsalade" gegeten.

De volgende opmerking vind ik hier een goed voorbeeld van, dit dwingt mij tot nadenken en argumenteren.

Dat is m.i. wel de optimale situatie. Als van elke onversleutelde bit (input) de kans exact 50% is dat deze wijzigt als gevolg van de versleuteling, weet je zeker dat er geen bias is.

Ja, maar hoewel wellicht een statistische of zelfs filosofische discussie (in beide ben ik geen held), is dat niet het gevolg van het feit dat je per bit niet moet kunnen voorspellen dat deze gewijzigd is of niet? Of hebben we het effectief gewoon over hetzelfde?

Wat vind je dan van de volgende stelling:

een goed encryptie algoritme kan worden gebruikt als een secure random number generator.

Voorbeelden AES die je volgens de NIST richtlijn 800-90A gebruikt.

Voor degenen die zich willen verdiepen, er is een gratis MOOC van Stanford university genaamd Cryptography I (II komt steeds maar niet uit helaas) van Dan Bone, pittig maar zeer de moeite waard.

1. Het aantal mogelijke permutaties is inderdaad beperkter dan wat men ons wil doen geloven er vanuitgaande dat de set van bytes in clear text met name de kleine letters bevat.
2. De informatietheoretische problematiek zit hem in de combinatorische complexiteit waarbij deze exponentieel toeneemt naarmate het aantal bytes aanzienlijk groter wordt. Waardoor het aantal mogelijke combinaties explodeert bij alrelatief weinig bytes. Waar wel weer tegenover staat dat cryptoanalytisch gezien sommige waarden bij het versleutelen van gestandariseerde content zoals http headers en html tags van bijvoorbeeld standaard pagina's die banken gebruiken een redelijke set van known clear text elementen oplevert in de versleutelde set. Dit biedt in sommige gevallen mogelijkheden die nog maar weinig publiek besproken worden in de vorm van wiskundige grootheden die onderbouwd zijn... ;)

My two cents...

De stelling is leuk, maar in de realiteit kan er bij encryptie ook gebruik worden gemaakt van padding of rotation. Iemand die de encryptie wil kraken en alleen de versleutelde data heeft, kan niet zien welke bits padding zijn en welke bits het originele deel.

Laten we voor het gemak een versleutelde harde schijf uit een Windows-laptop nemen. De aanvaller weet dat er een sowieso enkele Windows-Executables (cmd.exe, wordpad.exe,...enz) op staat. De aanvaller gaat dan op zoek naar de MZ-header (https://en.wikipedia.org/wiki/DOS_MZ_executable), omdat hij weet dat deze onvercijferd gelijk is aan 0100 1101 0101 1010.

Als de encryptie per iedere 8bits padding zou gebruiken kan er bv. dit van gemaakt worden:
0100 1101 1100 0011 0101 1010 0101 0101 (MZ-header van CMD.exe met 8bits padding)
0100 1101 0001 1101 0101 1010 1110 0010.(MZ-header van Wordpad.exe met 8bits padding)

We roteren de bits 1 slag linksom:

Voor de slag (MZ header CMD): Voor de slag (MZ header Wordpad:
0100 1101 0101 1010 0100 1101 0001 1101
1100 0011 0101 0101 0101 1010 1110 0010

Na de slag (MZ header CMD): Na de slag (MZ header Wordpad):
1100 0100 0101 0101 0101 0100 1110 0001
0011 1101 0101 1010 1010 1101 0010 1101

Achter elkaar zetten:
1100 0100 0101 0101 0011 1101 0101 1010 (MZ HEADER CMD ENCRYPTED)
0101 0100 1110 0001 1010 1101 0010 1101 (MZ HEADER WORDPAD ENCRYPTED)

En deze twee strings staan dus ergens in een versleuteld bestand van miljarden bits.. Succes met achterhalen!!

Eh, nee .

Het _eind_ resultaat van (goede) encryptie is niet van random te onderscheiden , en heeft _dus_ een verhouding van 50/50 tussen 0 en 1 .

De input daarintegen is (meestal) absoluut niet random , en kan een heel erg scheve verhouding hebben tussen 0 en 1 bits.
Ook als je een file van allemaal nullen, of allemaal enen encrypt is het eindresultaat iets wat niet van random te onderscheiden is.
En als je tekst encrypt , zijn de hoogste bits (bit 7 en 6) nogal vaak 0 - ook dan werk je met input met een scheve verhouding van 0/1 , en die scheve verhouding zie je niet terug in de gecrypte output.

Even heel duidelijk : encryptie behoudt wel de informatie, maar *JUIST NIET* de statistiek van de plaintext .

Cryptologie is ook statistiek begrijpen.
Als de verdeling van iets bestaande bekend is kun je het flippen dusdanig inregelen dat er random 50/50 verdeling uit komt.

Er is geen enkel reden om altijd van een normale verdeling gaussian uit te gaan.

Het drie deuren probleem met een baysian veronderstelling is leuker om over na te denken. Monty hall als je er op wilt zoeken.
Heb je een bepaalde kennis van de situatie dan kan je het resultaat anders inschatten dan als je die niet hebt.
De clou in het het betreffende spelprogramma. .. wisselen geeft het beste resultaat. Nagespeeld bij de Mythbusters.

De stelling is leuk, maar in de realiteit kan er bij encryptie ook gebruik worden gemaakt van padding of rotation. Iemand die de encryptie wil kraken en alleen de versleutelde data heeft, kan niet zien welke bits padding zijn en welke bits het originele deel.

Laten we voor het gemak een versleutelde harde schijf uit een Windows-laptop nemen. De aanvaller weet dat er een sowieso enkele Windows-Executables (cmd.exe, wordpad.exe,...enz) op staat. De aanvaller gaat dan op zoek naar de MZ-header (https://en.wikipedia.org/wiki/DOS_MZ_executable), omdat hij weet dat deze onvercijferd gelijk is aan 0100 1101 0101 1010.

Als de encryptie per iedere 8bits padding zou gebruiken kan er bv. dit van gemaakt worden:
0100 1101 1100 0011 0101 1010 0101 0101 (MZ-header van CMD.exe met 8bits padding)
0100 1101 0001 1101 0101 1010 1110 0010.(MZ-header van Wordpad.exe met 8bits padding)

We roteren de bits 1 slag linksom:

Voor de slag (MZ header CMD): Voor de slag (MZ header Wordpad:
0100 1101 0101 1010 0100 1101 0001 1101
1100 0011 0101 0101 0101 1010 1110 0010

Na de slag (MZ header CMD): Na de slag (MZ header Wordpad):
1100 0100 0101 0101 0101 0100 1110 0001
0011 1101 0101 1010 1010 1101 0010 1101

Achter elkaar zetten:
1100 0100 0101 0101 0011 1101 0101 1010 (MZ HEADER CMD ENCRYPTED)
0101 0100 1110 0001 1010 1101 0010 1101 (MZ HEADER WORDPAD ENCRYPTED)

En deze twee strings staan dus ergens in een versleuteld bestand van miljarden bits.. Succes met achterhalen!!

Dan heb je dus wel iets gesteld over de verhouding 0 en 1, namelijk dat die behouden/(vergelijkbaar) is tussen de plaintext en ciphertext versies .

En, zoals ik al schreef, in het extreme geval van een 100% 'verhouding' (file van allemaal nullen, of file van allemaal enen) zou in jouw stelling die verhouding zich moeten voortzetten in de ciphertext , na encryptie .
Je ziet toch hopelijk dat dit de consequentie is van wat je stelt ?

Dat is niet zo. (kijk gewoon - haal een paar MB aan nullen door AES , en tel de verhouding 0 en 1 bits na encryptie ).


Versleuteling op bit-niveau is niet geïnteresseerd in hoe karakters in tekst worden gecodeerd.
[/quote]
Dat klopt - maar de encodering zorgt , naast de 'gewone' (niet-random) statistische eigenschappen van tekst nog voor een heel duidelijke bias in het aantal 1 en 0 bits in de plaintext .
En jij had de stelling dat die bias in de verhouding 0:1 bits zichtbaar zou blijven in de ciphertext .


Dat stel je heel duidelijk maar heb je ook een onderbouwing? (N.B. gebruik van zaken als RLE is natuurlijk valsspelen want dat is geen versleuteling maar compressie.)[/quote]
Uit de statistiek van plaintext kun je informatie van/over die plaintext afleiden - het _is_ informatie.
Encryptie die zulke statistiek laat doorlekken naar de ciphertext voldoet niet .

De term 'distinguishing attack' wordt gebruikt voor methoden om ciphertext te onderscheiden van "random" .
Een goede encryptie moet daar tegen bestand zijn - oftewel, ciphertext moet niet van random te onderscheiden zijn .
Niet van random te onderscheiden wil zeggen (o.a. - het is noodzakelijk maar niet voldoende) dat er geen bias is voor 0 of 1 bits .

De plaintext daarintegen, is vrijwel altijd "niet random" - en statistisch dus heel erg onderscheidbaar van random en kan heel erg biased zijn - zoals files met veel nullen. Dat statistische onderscheid verdwijnt in de encryptie .

Maar als er altijd precies 50% van de bits flippen, dan is dat informatie voor degene die het probeert te ontsleutelen.
En dat is nu juist wat je niet wilt: het beste is dat degene die probeert te ontsleutelen geen poot heeft om op te staan.

Mooi voorbeeld. Hier zit 5x een letter "a" in, en dus zijn er 5 kansen dat er een letter a blijft staan na encryptie.

Er mankeert nog iets aan deze stelling. Moet zijn:
na goede versleuteling van een groot bestand heeft ongeveer de helft van de bits nog de oude, onversleutelde, waarde.

Bij zeer kleine bestanden kunnen er afwijkingen ontstaan. Want per bit is de kans dat het flipt meestal een half.
Dat houdt in dat bij een zeer klein bestand van bijv. 1 karakter (8 bits) er een kans van 1 op 256 is dat zelfs geen enkel bit is geflipt. (huh geflipte bits? 't is wat tegenwoordig ;-)
Dat is niet erg.
Want iemand die niet weet dat er "aardappelsalade" staat, weet toch niet of die a daar plain hoort te blijven staan of niet.
In geval van "aardappelsalade" heb je 5 x een kans dat één letter "a" hetzelfde blijft na encryptie. (bijna 2% kans dus)

Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, wat fijn... ;-)

Het grootste probleem in deze stelling is dat de encryptie gebeurd over blokken. Dus niet per karakter. Hierdoor is een blok onleesbaar geworden en is het redelijk onbegonnen werk (bij een geode encryptie) om te gaan raden welke bits niet goed staan.

Dus stelling 2 klopt alleen bij een simpele encryptie van 1 8 bits karakter.

Er zullen niet vaak precies 50% van de bits flippen, maar dit is wel het streven. Alles minder of meer dan exact 50% betekent dat er sprake is van bias, en als dat reproduceert helpt dat degene die probeert te ontsleutelen.

Waarom denk jij dat exact 50% flippende bits een aanvaller zouden helpen (anders dan een onderbuikgevoel)?

Als je precies 50% moet aanhouden is de wisseling zoals kmkmkmk exact voorspelbaar dit us in het extreme maar toont de gedachtenvalkuil.
Het otp met een boek gebruikt de zelden niet symmetrische verdeling als de tekst. Hoe die twee asymmetrische verdelingen uitwerken is een doordenker.
Met zippen rle etc verleg je dat naar iets als niet ter zake doende. Het inpakken van een goed geencrypt bestand zal leiden tot een groei van de omvang.

Voorbeeld 1:
Gegeven: 2 bits encrypted waarde 10
Er is precies 50% (de helft) van deze bits geflipt.
Conclusie: mogelijke decrypted waarden zijn 00 (1ste bit geflipt) of 11 (tweede bit geflipt)

Voorbeeld 2:
Gegeven: 2 bits encrypted waarde 10
Onbekend hoeveel bits er zijn geflipt.
Conclusie: mogelijke decrypted waarden zijn 00, 01, 10 of 11

In tweede voorbeeld heb je 2 keer zoveel opties,
dus in dit geval dubbel zo moeilijk om te raden wat de decrypted waarde is.

De term 'exact' staat een beetje haaks op het begrip 'random' en 'kansverdeling' , maar het is wel een heel scherpe piek.

De ciphertext van een goed algorithme is niet van random te onderscheiden - dat betekent dat elke bit een kans van 50% heeft om een 1 te zijn (en dus ook een kans van 50% om een nul te zijn ).

Voor het aantal enen en nullen in het totale bericht zijn de kansen op waarden rondom 'evenveel' erg hoog, en hoe verder weg je komt van een 50:50 verhouding , des te kleiner wordt de kans op die uitkomst .
Maar het is dus een spreiding _rondom_ 'evenveel' die een hoge kans heeft .

Als je 10x een eerlijk muntje op gooit, is de kans op 10x kop (of 10x munt) klein (0.1 %) . De kans op 5 kop / 5 munt , 4 kop/6 munt, 6 kop/4 munt is groter.
(Dit is gewoon 4 of 5 VWO, hooguit . Nuttig om uit te schrijven en te tekenen als je er geen gevoel bij hebt)

Als je 100x een muntje opgooit, wordt de piek van tussen de 40 en 60 kop/munt heel scherp .

De verhouding 0/1 in ciphertext gedraagt zich net zo. En voor de lengtes van een beetje bericht zit je al heel snel aan de 1000 bits - en dus een heel scherpe piek

Goede cursus, maar voor sommigen denk ik net te lastig vanwege de vrij wiskundige benadering van de leerstof (en de snelheid waarop hij praat en de stof behandelt). Een andere, minder wiskundige en ook minder snelle behandeling van de cryptografie is de online cursus van Christof Paar, een Duitse prof: https://www.youtube.com/watch?v=2aHkqB2-46k&list=PL6N5qY2nvvJE8X75VkXglSrVhLv1tVcfy. Goede selectie van onderwerpen, ook voor de beginner goed te volgen (als je er tenminste tijd in stopt), een goede website met veel ondersteunend materiaal (http://www.crypto-textbook.com/) en uitdagend genoeg om het basisniveau cryptografie te ontstijgen. Veel van de zaken die in deze thread worden aangekaart worden in die cursus ook besproken.

Bij "2" gaat de wet van de wat grotere getallen nog niet zo hard op.

Elke bit heeft 50% kans om te wijzigen. Over de totale lengte van de input geeft dat een heel grote waarschijnlijk dat het aantal gewijzigd : niet gewijzigd op vrijwel 50/50 uitkomt .
Bij een input van lengte 2 is dat verschil niet zo groot als bij een input van een paar honderd bits - laat staan bij een paar miljoen bits.

(zie ook mijn muntjes gooien uitleg van 12:03 )

Dat klopt wel, maar die voorwaarde was oorspronkelijk niet gesteld. ;-]
Je zou kunnen zeggen: bij exact 50% kans (per bit van het bestand dat ie flipt) zal bij een oneindig groot bestand
precies 50% van alle bits zijn geflipt. Maar zo niet, dan kunnen er afwijkingen zijn van die exacte 50%,
en de kans op afwijkingen is groter naar mate het bestand kleiner is. (zie ook Vandaag, 12:03 door Anoniem)
Andersom: naarmate een bestand groter is, zal in de praktijk het aantal geflipte bits steeds minder afwijken van die 50%.
Maar stel nu eens dat je een zgn. bias hebt, en de kans op een geflipte bit bij ieder bit bijv. 40% is.
Is een tekst dan gemakkelijker of moeilijker te ontsleutelen? (aangenomen dat de ontvanger de encryptiemethode niet kent, en dus niet weet dat bij elk bit de kans op een geflipt bit 40% is, en misschien juist wel denkt dat het heel dicht in de buurt van 50% geflipte bits moet uitkomen).

Ik was de 12:03 (en 15:55) anoniem, en ik zal dus ook zeker niet zeggen dat een exacte 50% flip kans een _garandeerde exacte_ 50/50 verdeling in het eindresultaat oplevert.
Alleen iets wat dicht rondom de 50:50 ligt.


De ontvanger constateert ( zoals ik ook schreef op 01-02 13:36 ) dat een distinguishing attack mogelijk is : de ciphertext is herkenbaar 'niet random'.
Het is een ernstige zwakte in een algorithme - en kan vaak leiden het verder lekken van informatie uit de plaintext . Soms genoeg om daaruit verdere aanvallen op te bouwen.
RC4 is een voorbeeld van een algorithme met een biased output - en van daaruit viel veel te bereiken .

"Exact" en "dicht rondom" spreekt elkaar tegen.

In RC4 zat een ander soort "bias".
Die bias zat hem hierin dat de eerst 256 bits enigszins vergelijkbaar waren.
Had niet zozeer te maken met al of niet een 50/50 verdeling van de hele stream.
Maar meer dat die 50/50 verdeling in de eerste 256 bits ietwat neeg naar vergelijkbaar resultaat.
En dat was in de eerste 256 bit kwalijk, vanwege de sessioncookie die zich daar meestal bevindt.
Van zo'n sessioncookie staan bovendien een aantal karakters op bepaalde locaties al vast, en dat kan al met al een attacker verder helpen om met teveel zekerheid de hele sessioncookie bloot te leggen.
(met als gevolg dat de session overgenomen kan worden door de attacker)

Misschien ten overvloede na de antwoorden die al gegeven zijn:

Het streven is niet om 50% van de bits te flippen, het streven is om in de uitvoer geen herkenbare patronen te hebben, wat impliceert dat elke bit in de uitvoer 50% kans op 0 en 50% kans op 1 heeft, en dat impliceert weer dat elke afzonderlijke bit 50% kans heeft om te flippen (voor wie dat niet inziet: verdiep je in one-time pads, als je die snapt valt dit muntje ook). Het is geen streven, het is een consequentie van een streven.

En het gaat nadrukkelijk om onafhankelijke kansen, elke herkenbare afhankelijkheid tussen bits in het versleutelde bericht geeft informatie aan een aanvaller en is daarmee een verzwakking van de encryptie. Al geef je als je streeft naar exact 50% geflipte bits maar één bit prijs, ik kan me niet voorstellen dat welke ontwikkelaar van cryptografische algoritmes dan ook het in zijn hoofd haalt om naar zoiets te streven. Als je jezelf een beperking in de onafhankelijkheid van de bits oplegt lever je vrijheden in bij het streven naar een maximale onvoorspelbaarheid, met het risico dat dergelijke beperkingen meer problemen introduceren dan alleen die ene bit. Ik vermoed dat een algoritme dat die eigenschap blijkt te hebben onmiddelijk als verdacht wordt aangemerkt door deskundigen.

Als de kans per bit, onafhankelijk van andere bits 50% 0 en 50% 1 is, dan treden kleine afwijkingen van een 50/50-verdeling vrijwel zeker op, maar hoe groter het bericht is hoe kleiner de relatieve afwijking gemiddeld is, zoals iedereen met basiskennis van statistiek zal kunnen bevestigen. Bij een hoeveelheid bits die werkelijk random zijn zie je hetzelfde beeld, en het streven is om daarvan niet te onderscheiden te zijn. Het altijd ontbreken van die verwachte afwijkingen maakt juist duidelijk dat die bits niet random zijn, en dat levert ook een zwakte op als het doel is om encryptie niet als zodanig herkenbaar te maken.

Absoluut, maar hoeft niet te zeggen dat er geen 50% van de encryptie-stream een geflipt bit kan zijn.
Wel dat de bits afzonderlijk geen 50% kans op een geflipt bit hadden.

Exteem voorbeeld: stel de bias in de encryptie-stream is dat elk volgend bit steeds veranderd.
Je krijgt dan bijvoorbeeld: 0101010101010101010101010101010101010101010101
Nog steeds wordt hiermee 50% van de bits geflipt.
Maar alle volgende bits van deze stream liggen 100% vast bij het schrijven van de eerste bit.
M.a.w.: behalve voor het eerste bit geldt er voor de rest van de stream niet dat één enkel bit 50/50 kans heeft op 0 of 1.
Want vanaf het tweede bit is de waarde van elk volgend bit 100% afhankelijk van zijn voorganger.

Dus in aanvulling op:
Stelling 1: na goede versleuteling van een bestand heeft ongeveer de helft van de bits nog de oude, onversleutelde, waarde
is nu wel bewezen dat:
Als ongeveer de helft van de bits nog de oude, onversleutelde waarde heeft, wil dat niet per se zeggen dat de versleuteling goed is! ;-)

Dat is in geval er tussen bits een vast statistisch verband bestaat. (zoals bij RC4 is geconstateerd)

Als ik ze voor hetzelfde begrip zou gebruiken wel ja.

100x gooien met een exact zuivere munt (50/50 kans op kop/munt) levert geen _exact gegarandeerde_ uitkomst van 50x kop, 50x munt op.
Maar een spreiding die daar dicht bij in de buurt zit, met een bijzonder kleine kans op 100 kop en geen munt, en een heel grote kans op 50+-10 kop/munt.
Gewoon basis statistiek.


Natuurlijk was de bias van RC4 iets anders dan de bit verhouding over de hele stream.
Maar laat men RC4 maar zien als voorbeeld en waarschuwing dat "een beetje bias, wat kun daar nou echt mee ontsleutelen" een gevaarlijk foute redenering kan zijn.

Ok, wat dat betreft zijn we het altijd al eens geweest.

Het was dat je 15:55 bezwaar maakte dat mijn eerdere voorbeeld over "slechts 2 bits" ging.
Maar dat was met opzet een extreem voorbeeld en bewijs van hoe een attacker wordt geholpen in geval het 100% zeker is dat exact 50% van de bits zou flippen. Dat was toen namelijk de vraag!!! Meer niet. Gewoon een antwoord op de vraag over hoe een attacker geholpen kan worden in het theoretische geval waarbij hij weet dat precies 50% van de bits is geflipt. Meer niet.

Uiteraard wordt het voor een attacker moeilijker bij langere bestanden, en leert de praktijk dat de verhouding tussen geflipte en niet geflipte bits meestal niet exact maar ongeveer 50/50 is. Maar dat neemt niet weg dat het informatie voor de attacker is. Het is alleen de vraag of dat genoeg is om de plain informatie bij lange bestanden bloot te kunnen leggen.
Maar het is en blijft hulpinformatie, hoe je het ook wendt of keert, en je mag dat wat mij betreft niet zomaar helemaal negeren.

De vraag is nu dan ook zoals eerder door mij gesteld:
waarom zou het slecht zijn om bijv. een verhouding van 60/40 te gebruiken op afzonderlijke bits die verder onafhankelijk zijn van elkaar. De attacker ziet namelijk niet de encryptie stream maar slechts de encrypted stream.

Alleen in geval het algoritme waarmee geëncrypt ook bij de attacker bekend is, en als dat algoritme altijd met 60/40 encrypt, dan kan die extra informatie kwalijk zijn, omdat hij dan dus weet dat bijv. 60% van de bits niet is geflipt.
Maar als hij dit niet weet, dan is het volgens mij niet kwalijk om ook eens met een 60/40 verhouding te encrypten.

Je kunt ook een bestand van 700MB zo bitflippen dat je een mooie DIVX video hebt van een willekeurige film.
In other words: Waar gaat dit over?

Inmiddels gaat het erover of de beste encryptie altijd een algoritme nodig heeft waarbij elk bit precies 50% kans heeft om te flippen. Wat is er mis met bijv. een 60/40 kansverdeling (per bit), waarbij je er voor zorgt dat een attacker niet weet dat het om een 60/40 verdeling gaat?

Helaas is het praktisch onmogelijk om een algoritme te verzinnen dat ieder bestand omtovert tot een mooie DIVX video,
maar anders zou dat ook een mooie methode zijn.

Je hebt gelijk!

Een aanvaller heeft er baat bij als hij weet dat, ongeacht de lengte van de versleutelde data, altijd precies 50% van de bits geswapped zijn.

Hoewel dit bij een zeer korte plaintext geen realistisch scenario is, ontdekte ik wel iets opmerkelijks dat ik niet had verwacht. Namelijk dat het aantal mogelijke combinaties van exact evenveel nullen en enen minder snel toeneemt naarmate de sleutel langer wordt:

2 bits: 2 van 4 mogelijkheden = 50% (01 en 10)
4 bits: 6 van 16 mogelijkheden = ca. 37.5% (0011, 0101, 0110, 1001, 1010, 1100)
6 bits: 20 van 64 mogelijkheden = ca. 31.3% (etc.)
8 bits: 70 van 256 mogelijkheden = ca. 27.3%
10 bits: 252 van 1024 mogelijkheden = ca. 24.6%
12 bits: 924 van 4096 mogelijkheden = ca. 22.6%
14 bits: 3432 van 16384 mogelijkheden = ca. 20.9%
16 bits: 12870 van 65536 mogelijkheden = ca. 19.6%
18 bits: 48620 van 262144 mogelijkheden = ca. 18.5%
20 bits: 184756 van 1048576 mogelijkheden = ca. 17.6%
22 bits: 705432 van 4194304 mogelijkheden = ca. 16.8%
24 bits: 2704156 van 16777216 mogelijkheden = ca. 16.1%
26 bits: 10400600 van 67198864 mogelijkheden = ca. 15.5%
28 bits: 40116600 van 268435456 mogelijkheden = ca. 14.9%
30 bits: 155117520 van 1073741824 mogelijkheden = ca. 14.4%
32 bits: 601080390 van 4294967296 mogelijkheden = ca. 13.9%
34 bits: 2333606220 van 17179869184 mogelijkheden = ca. 13.6%
etc. (m'n snel ingeklopte programma werd te traag hierna, en 32bit tellers zijn dan te klein)

Met andere woorden: als je weet dat een perfecte random number generator (per bit heb je 50% kans op een 0 of een 1, maar tegelijkertijd heeft bij een oneindig lange sleutel de helft van de bits de waarde 0) als sleutel is gebruikt, lijkt het zinvol om bij een "brute force" aanval te beginnen met sleutels met exact evenveel enen als nullen erin.

Nu bestaan perfecte random number generators niet voor zover ik weet, maar dan nog kan bovenstaande aanpak zinvol zijn als je daarna verder gaat met alle bitcombinaties waarbij er 2 nullen meer in voorkomen dan enen en andersom, daarna 4 nullen meer dan enen en andersom etc.


Oftewel, met dit inzicht heeft een aanvaller er baat bij als hij weet dat, ongeacht de lengte van de versleutelde data, ongeveer 50% van de bits geswapped zijn.

Ik ben benieuwd naar jullie reacties!

Heb er even een rekenformule voor je uit gedestilleerd (uitroepteken achter het getal betekent, zoals in de wiskunde gewoon is, de bewerking "faculteit" (3! = 1x2x3;... 4! = 1x2x3x4;... 5! = 1x2x3x4x5;... 6! = 1x2x3x4x5x6... enzovoorts):

Deze rekenformule luidt als volgt:
Als n het (even) aantal bits van een bestand is, dan is het aantal mogelijkheden met een exacte 50/50 verdeling:

n! / ((n/2)!)²

Voorbeelden:
Bij 20 bits: 20! / (10!)² = 184756
bij 22 bits: 22! / (11!)² = 705432
bij 24 bits: 24! / (12!)² = 2704156
etc.
Wel kans op enige rekenafwijkingen van je calculator als de getallen zo groot worden.

Bij 252 bits kom ik dan op 3,63385716E74 mogelijkheden met een exacte 50/50 verdeling
op een totaal aantal mogelijkheden van 7,23700558E75, en dat is nog steeds 5,02 % kans op een exacte 50/50 verdeling.


Goeroehoedjes! ;-)

Wat je ook kan doen is:
404x403x402x401x400x399x......enzovoorts........x205x204x203, en de uitkomst daarvan vervolgens delen door 202!.
Dat was ook wat ik oorspronkelijk had gevonden, maar is lastig rekenen bij niet programmeerbare calculators.
Voordeel is echter dat je calculator nog wat meer bits aankan voordat hij in overflow geraakt.

In geval er voor elk bit van het bestand een 50/50 kans bestaat dat het flipt of niet, kom ik dan uit op ca. 3,967% kans dat
dat het aantal enen en nullen in een bestand van 404 bits precies gelijk is.
(kans van ca. 1 op 25,2)

"Voor wat het waard is",


Goeroehoedjes

Ik moet tot de conclusie komen, dat bij een oneindig lange sleutel niet de helft van de bits de waarde 0 heeft.
Althans: niet exact de helft...
We zien immers in de tabel dat naar mate een bestand groter is, het procentueel steeds minder vaak voorkomt
dat het aantal enen en nullen precies gelijk is.

Dat grote bestanden steeds meer een 50/50 verhouding (lijken te) krijgen,
komt vooral omdat kleine afwijkingen procentueel maar weinig uitmaken in verhouding tot zo'n groot bestand.

Voorbeeld:
Je encryptiealgoritme levert 100 bits om een bestand van 100 bit mee te encrypten (m.b.v. XOR)
De geleverde encryptiebits bestaan bijv. uit 51 enen en 49 nullen. (51% enen, 49% nullen) Het verschil is 2%

Maar stel nu eens dat je een bestand van bijv. 100.000 bits hebt.
Het encryptiealgoritme levert nu 100.000 bits, bijv. 50.001 enen en 49.999 nullen. ( = 50,001% enen, en 49,999% nullen)
Wat blijkt?
De absolute afwijking (2) is hetzelfde, maar het procentuele verschil (2 op 100.000) is nu nog maar 0,002%

Geniaal!

Je hebt het (ook in je bijdrage van vanmiddag) over "kans", maar dat vind ik wat verwarrend. Immers ik ben op zoek naar alle combinaties van evenveel nullen als enen in een reeks bits van een gegeven (even) lengte; daar komt geen toeval bij kijken.

Waar ik uiteindelijk benieuwd naar ben, is of het zin heeft om bij een "brute force" aanval (in elk geval op met een one-time-pad of stream cipher, maar evt. ook bij block cipher, versleutelde data) niet te beginnen met 0, 1, 2, 3 etc. maar eerst met alle bitpatronen met een zelfde aantal enen en nullen, daarna ietsje meer nullen dan enen en vice versa etc. (zie het voorbeeld in mijn vorige bijdrage, en verderop in deze bijdrage).

In dat geval heeft de random number generator een bias (ervan uitgaande dat oneindig een even getal is, anders heb je gelijk :-).

Procentueel wel, maar absoluut niet.

Als een bitreeks 2 bits langer wordt kan hiermee een getal worden gerepresenteerd dat exact 4 keer zo groot is. Het aantal combinaties van exact evenveel nullen als enen neemt echter met iets minder dan een factor 4 toe. Maar toenemen doet het!

Ik denk dat het beter was geweest als ik niet over percentages was begonnen, want je hebt gelijk dat die erg klein worden in dit soort situaties.

Met jouw voorbeeld (100.000) bits en mijn aanname, dat de kans dat de random number generator evenveel enen als nullen genereert, toeneemt naarmate de (XOR) sleutel langer wordt (en maximaal, namelijk 1, is bij een oneindig lange sleutel - anders zou er sprake zijn van bias) lijkt het dus verstandig om een brute force aanval als volgt uit te voeren:
1) probeer eerst alle bitcombinaties van 50.000 nullen en 50.000 enen
2) probeer daarna alle bitcombinaties van 49.999 nullen en 50.001 enen
3) probeer daarna alle bitcombinaties van 49.999 enen en 50.001 nullen
4) probeer daarna alle bitcombinaties van 49.998 nullen en 50.002 enen
etc. (de keuze voor de volgorde van 2 en 3 is natuurlijk arbitrair).

Om het anders te stellen:
A) van een goede random number generator is de kans 50% dat elke gegenereerde random bit een 0 of een 1 is.
B) hoewel er natuurlijk geen sprake is van een bijstuurmechanisme en/of geheugen ("het vorige bit was 0 dus moet ik nu een 1 genereren" - dat zou 010101 etc. opleveren) moet (m.i.) bij grotere aantallen bits de verhouding tussen het aantal random gegenereerde nullen en enen steeds dichter bij 1:1 komen.

Als B niet klopt is er sprake van een bias en kan A ook niet kloppen!

Vergelijkbaar: hoe vaker je een perfecte dobbelsteen gooit, hoe dichter de gemiddelde worpwaarde bij 3,5 zal komen. Toch?

@Erik, Als je het nu eens achterstevoren probeert: je hebt het originele bestand, waar je de encryptie overheen laat gaan. Dan heb je dus 2 bestanden. Je laat daar diff (of een ander vergelijkingsprogramma) op los en kijkt dan, waar de verschillen zitten. Wellicht dat je op die manier het algoritme of parallellen kunt achterhalen? Ik heb niet zoveel verstand als jij met encryptie, maar misschien is dit een ideetje.
Hoop alleen dat de dvai niet meekijkt, misschien breng ik ze wel op ideeën.

Een statistische test ziet HEEL snel dat de output biased is - zeker als het zo bot is als 60/40 .

En wat voor threat model heb je in gedachten waarbij de aanvaller de _ciphertext_ niet zou zien ?
Dat een pruts-algoritme bruikbaar is als je het resultaat daarna nog eens goed encrypt ?
Dat is inderdaad wel de eis aan een goed algorithme , maar natuurlijk niet zinvol.

De standaard aannames zijn dat aan algorithme tot en met een chosen-plaintext aanval robuust moet zijn .
(oftewel - zelfs als de aanvaller zowel input bepaalt als output ziet er niks af te leiden valt over de sleutel ).

Feitelijk laat een bias informatie lekken van input naar output, die vaak en veel bruikbaar kan zijn voor verdere decryptie.



Makkelijk : de methode is : XOR een bestand met een mooie DIVX video .

Decryptie is nogmaals XOR met dit bestand, en voila, daar is je DIVX video weer.

(nee, het is geen sterke encryptie, of universele compressie, maar het voldoet aan je eis...)

Ah OK. Ik had er een andere betekenis in gelezen.

Als ik het voor mezelf formuleer : een eis voor _exact evenveel aantal nullen in enen_ in het resultaat betekent dat correlatie zit tussen de verschillende bits.
En in het extreme geval van 2 bits legt de waarde van de eerste bit de waarde van tweede bit 100% vast .

Correlatie tussen bits staat haaks op de eis 'niet van random te onderscheiden' - random bits hebben geen onderlinge correlatie.


Zo'n botte bias ziet een statistische test heel erg snel.
En met enig herhaald gebruik middelt een herhaalde of herkenbare plaintext zich er heel snel uit.

Dat komt omdat het aantal worpen (noemer van de breuk) toeneemt bij het uitrekenen van de gemiddelde waarde.
En eh...je gooide niet één keer 3,5... ;-)

Als het om het totale aantal combinaties gaat: 252 bits kun je vergelijken met een binaire teller van 252 bit.
Deze kan 2^252 verschillende waarden aannemen. Er zijn dus 2^252 verschillende bitcombinaties mogelijk.
Dat zijn er ongeveer 7,23700558 x 10^75. En slechts 1 van die combinaties is de juiste.

Ja, er bestaat statistisch gezien een voorkeur voor combinaties met evenveel nullen als enen. Dat is bewezen.
Dat blijken er hier 3,63385716 x 10^74 te zijn, en is ongeveer 5,02% van het totale aantal mogelijke combinaties.
Maar iedere bitcombinatie van 252 bits heeft evenveel kans.
En er bestaan bij 252 bits ook nog 94,98% andere combinaties, die niet uit evenveel nullen en enen bestaan.

Je hebt bij 252 bits dus een kans van 5,02% (bijna 1 op 20) dat je met zoeken naar precies evenveel nullen en enen
goed zit, en daarvoor zul je als er verder geen extra gegevens zijn misschien wel 3,63385716 x 10^74 combinaties met evenveel nullen als enen moeten proberen..., met een kans van 1 op 20 dat het uitproberen van die combinaties succesvol is.
Maar je zou bijv. ook de combinatie kunnen proberen die volledig bestaat uit nullen.
Daar is er maar één van. De kans dat je goed zit is 1 op 2^252, maar je bent wel lekker snel klaar... ;-)

Ik denk dat het hem hier in zit:
de kans op een combinatie met evenveel enen als nullen is het grootst, maar juist omdat het er zo veel zijn,
moet je dus waarschijnlijk erg veel combinaties met alleen nullen en enen uitproberen.
De kans op een andere verdeling van nullen en enen is kleiner, maar omdat er minder combinaties van zijn,
hoef je minder combinaties uit te proberen, en ben je er eerder klaar klaar mee.

Ik denk dat het uiteindelijk allemaal niets uit maakt: iedere combinatie maakt evenveel kans dat je hem "toevallig" vindt.
Hoe klinkt dat? ;-)

Goeroehoedjes

Busted!

Er is helemaal geen garantie dat er bij een oneindig groot bestand precies 50% van alle bits is geflipt.

Bijvoorbeeld stel dat een bestand "bijna oneindig" is, en er op dat moment toevallig exact 50% van de bits is geflipt.
Dan nog kun je er enkele bits aan toevoegen, en op de toegevoegde bits een XOR doen.
Zie de tabel van Erik ( 05-02-2017, 19:01 door Erik van Straten - Bijgewerkt: 05-02-2017, 21:52.
We zien aan die tabel dat het minder dan 50% van de gevallen voorkomt dat hierin evenveel enen als nullen zitten.
En dus zullen er na toevoeging waarschijnlijker ook niet meer precies evenveel nullen als enen voorkomen in het
"nu iets langer dan bijna oneindige" bestand. Hoever je ook richting oneindig gaat, dit blijft steeds gelden.

Conclusie:
de stelling dat er in een oneindig groot digitaal (encryptie)bestand precies even veel enen als nullen zouden zitten,
(zodat exact 50% van de databits zou flippen) is onjuist.

Alle bits flippen. Dat deden ze toch bij encryptie van analoge foto's :). Vreemd genoeg was het orgineel toch altijd veel kleiner.

De crux zit hem in het achterhalen welke bits er zijn geflipt. Dat heet encryptie!

Leuke stellingen maar een beetje te vreemd om serieus te nemen.