[Disc] ROT13, encryptie of niet?

[emnich]

incaz schreef op woensdag 10 juni 2015 @ 17:38:
[...]
Duits lijkt mij vooral geen encryptie omdat het niet uniek reversibel is - bij de vertaling de een of de andere kant op kunnen er afwijkingen optreden, omdat natuurlijke talen een heleboel ambiguiteiten kennen.

Dat hebben we al eerder behandeld. Een input in Google translate levert altijd dezelfde output op, is het daarmee dan toch encryptie?

(Overigens, je maakt een logicafout. Niemand hier zegt dat alle manieren om een boodschap te verbergen voor (bepaalde) toehoorders dus automatisch encryptie genoemd moeten worden.)

Hm, niet alle maar Duits, morse, het uitprinten van broncode, een word document is hier al encryptie genoemd. Zolang het maar verborgen wordt voor een specifiek iemand kon het encryptie genoemd worden.

Wat is jouw definitie dan van encryptie? Dat is namelijk de enige manier om te bepalen of rot13 voldoet of niet.

[ Voor 4% gewijzigd door emnich op 10-06-2015 17:51 ]

[begintmeta]

Voor mij gaat het nog steeds om de intentie. Dat lijkt me het duidelijkst, ook omdat je "nooit kan weten" hoe makkelijk een ander het kan lezen.

[incaz]

Brent schreef op woensdag 10 juni 2015 @ 17:40:
Dat hebben we al eerder behandeld. Een input in Google translate levert altijd dezelfde output op, is het daarmee dan toch encryptie?

Nee, want de output moet vervolgens ook weer terug te vormen zijn naar de input. En dat doet Google translate zeker niet.

Hm, niet alle maar Duits, morse, het uitprinten van broncode, een word document is hier al encryptie genoemd.

Wat is jouw definitie dan van encryptie? Dat is namelijk de enige manier om te bepalen of rot13 voldoet of niet.

Kenmerken voor mij zijn
- de boodschap zo veranderen dat deze niet leesbaar is als algoritme en sleutel niet bekend zijn
- een ieder die algoritme en sleutel wel hebben kunnen de boodschap weer terugbrengen in de oorspronkelijke vorm.
.. en ik denk dat het kiezen van een algoritme en sleutel die voldoende zijn voor je doel belangrijk zijn, maar dat is niet goed in een definitie te vatten.

Dat is ook een beetje waar de discussie op neer komt - het is geen binaire eigenschap, het gaat uiteindelijk vooral om of het voldoende encrypted is voor het doel dat de verzender in gedachten heeft.

[RayNbow]

.oisyn schreef op woensdag 10 juni 2015 @ 17:09:
[...]


Poll: ROT13 kan worden geclassificeerd als encryptie
• Eens
• Niet mee eens
• Geen mening
^Tussenstand:
[afbeelding]

Gemiste kans: de opties versleutelen met ROT13.

[Amanush]

ROT13 is encoding.. geen encryptie. Punt.

Hedendaagse methoden zijn slechts encryptie als er een key aan te pas komt.

Als ROT13 encryptie is, is Base64 ook encryptie. Wikipedia vermeld dat Base64 "encoding" is. ROT13 is volgens Wikipedia encryptie.

Ergens zit dus een fout, want beiden doen exact hetzelfde; een string omzetten naar een net iets andere string, die je weer kan terug-omzetten naar de oude staat.

[ Voor 67% gewijzigd door Amanush op 11-06-2015 07:25 ]

[Sebazzz]

Een encoding is een representatie van data. Encryptie is iets versleutelen met het doel dat een onbekende partij dit niet zomaar kan lezen.

ROT13 is simpelweg rotatieversleuteling, zoals al gezegd is. De sleutel is echter 13. Je moet ROT13 niet als aparts zien maar simpelweg als:

code:

fn rot(key, text) {
   // ...
}

fn rot13(text) {
   return rot(13, text);
}

[RayNbow]

Sebazzz schreef op donderdag 11 juni 2015 @ 08:27:
Je moet ROT13 niet als aparts zien maar simpelweg als:

code:

fn rot(key, text) {
   // ...
}

fn rot13(text) {
   return rot(13, text);
}

Jng, trra rraf rra jrexraqr vzcyrzragngvr mbnyf vx va EnlAobj va "[Qvfp] EBG13, rapelcgvr bs avrg?" trtrira uro?

[Amanush]

Sebazzz schreef op donderdag 11 juni 2015 @ 08:27:
Een encoding is een representatie van data. Encryptie is iets versleutelen met het doel dat een onbekende partij dit niet zomaar kan lezen.

ROT13 is simpelweg rotatieversleuteling, zoals al gezegd is. De sleutel is echter 13. Je moet ROT13 niet als aparts zien maar simpelweg als:

code:

fn rot(key, text) {
   // ...
}

fn rot13(text) {
   return rot(13, text);
}

"Ik ga akkoord" met jouw uitleg. ROT is een encryptie-algoritme. Je hebt gelijk.

[jbdeiman]

emnich schreef op woensdag 10 juni 2015 @ 17:50:
[...]

Dat hebben we al eerder behandeld. Een input in Google translate levert altijd dezelfde output op, is het daarmee dan toch encryptie?

Deze snap ik niet, nu trek je het wel heel breed:
SHA512 (bijvoorbeeld!) geeft bij dezelfde input altijd hetzelfde resultaat (dezelfde output), dezelfde teksten die je beveiligd met jou sleutel, zijn ook met jou sleutel weer leesbaar te krijgen, ook hier: dezelfde input geeft dezelfde output. Dus tjah, of de output (bij dezelfde input) altijd hetzelfde is, zegt niets over of het encryptie is of niet.
Als je het heel versimpeld bekijkt is encryptie juist een vertaalmechanisme, waarbij de vertaling (en dus ook de redenering terug naar de originele waarde) afhankelijk is van de gekozen methode:
- Letters verschuiven (ROT methodiek)
- Omzetten naar bitjes en daar een verschuiving op toepassen (met bepaalde sleutel)
- Combinaties (bijv woorden + letters husselen op basis van één of meerdere sleutels)

Hoe dan ook:
Heb jij de sleutel kan je begrijpen wat er bedoeld wordt. Als ik nu een tekst naar het chinees zou zetten kan je het chineese woordenboek (maar bijv ook een vertaal-tool of zelfs een vertaler) gebruiken als sleutel, om de tekst weer begrijpbaar te maken.

Het is ook niet voor niets dat encryptie erop neer komt dat je terug kan naar de oorspronkelijke waarde en dat (als het goed is) wachtwoorden juist worden gehasht omdat deze alleen met de hash op basis van gebruikers input vergeleken moeten worden en bij voorkeur niet zomaar (met een simpele sleutel) terug te redeneren zijn.

Amanush schreef op donderdag 11 juni 2015 @ 07:20:
ROT13 is encoding.. geen encryptie. Punt.

Hedendaagse methoden zijn slechts encryptie als er een key aan te pas komt.

Als ROT13 encryptie is, is Base64 ook encryptie. Wikipedia vermeld dat Base64 "encoding" is. ROT13 is volgens Wikipedia encryptie.

Ergens zit dus een fout, want beiden doen exact hetzelfde; een string omzetten naar een net iets andere string, die je weer kan terug-omzetten naar de oude staat.

Zie reactie hierboven aan emnich: Als je iets om kan zetten naar een versleutelde string en weer terug is het geen encryptie? Volgens mij gaat het wanneer je het juist niet meer (zomaar) om kan zetten eerder om een hash methodiek dan om encryptie.

[ Voor 25% gewijzigd door jbdeiman op 11-06-2015 09:05 ]

[.oisyn]

Amanush schreef op donderdag 11 juni 2015 @ 07:20:
ROT13 is encoding.. geen encryptie. Punt.

Hedendaagse methoden zijn slechts encryptie als er een key aan te pas komt.

Als ROT13 encryptie is, is Base64 ook encryptie. Wikipedia vermeld dat Base64 "encoding" is. ROT13 is volgens Wikipedia encryptie.

Ergens zit dus een fout, want beiden doen exact hetzelfde; een string omzetten naar een net iets andere string, die je weer kan terug-omzetten naar de oude staat.

Tja, kijk, als je al niet eens de moeite neemt om andere reacties in de topic door te lezen en daarop voort te borduren, reageer dan gewoon niet

[Laurens-R]

Los van de heftige discussie lijkt het er wel op - uitgaande van de poll - dat het overgrote merendeel van de dev'ers hier vinden dat ROT13 gewoon encryptie (myself included). Niet een sterke encryptie, maar desalniettemin encryptie.

Simpel gezegd komt het wel ongeveer neer op wat Sebazzz zei:

Een encoding is een representatie van data. Encryptie is iets versleutelen met het doel dat een onbekende partij dit niet zomaar kan lezen.

Rot encryptie (beter bekend als Caesar cipher) was - gekscherend gezegd - de 'SSL' van het romeinse rijk. Ceasar gebruikte het om in alle veiligheid met z'n generaals te kunnen communiceren. Je doet wat mij betreft het idee achter encryptie tekort als je het puur betrekt op het hier en nu in het digitale tijdperk.

Daarmee is het natuurlijk wel logisch dat in deze tijd de focus primair ligt op het digitale domein en daarmee encryptie direct samenhangt met informatieversleuteling. Encryptie kan je echter natuurlijk net zo makkelijk toepassen op rooksignalen, geluid, inkt, etc.

[ Voor 5% gewijzigd door Laurens-R op 11-06-2015 13:48 ]

[Gimmeabrake]

ROT13 kan worden geclassificeerd als encryptie, maar ook de Duitse taal en een geschreven briefje kunnen als encryptie geclassificeerd worden. De reden dat ik het eens ben met de stelling is voornamelijk het woord "kan"; of iets als encryptie te classificeren valt hangt mijns inziens namelijk af van de intentie en van de deelnemers.

Uiteindelijk is het zo dat je bij encryptie 3 partijen hebt, verzender(s) A, ontvanger(s) B en publiek C. A en B willen veilig informatie uitwisselen(intentie) maar weten dat ze niet kunnen voorkomen dat het medium wordt onderschept door het publiek C. Door middel van encryptie transformeren ze het bericht zo dat het in de tijd dat het onderschepbaar is, niet te begrijpen valt. Of het onderschepte bericht te begrijpen valt hangt af van de deelnemers: Wie zijn A, B en C en over welke mogelijkheden beschikken ze?

Afhankelijk van de situatie zijn bepaalde methodes daardoor soms wel of geen encryptie te noemen. Anno nu kun je als software ontwikkelaar rot13 niet als encryptiemethode beschouwen omdat het publiek tegenwoordig gewoon mee kan lezen: rot13 stelt voor een hacker, het "publiek" waar een software developer mee moet rekenen, geen drol voor. Ouders kunnen Duits wel als encryptiemethode gebruiken bij een jong Nederlands kind, en ook het schrijven van berichten bij analfabeten is een vorm van encryptie mits je de intentie hebt om specifiek de analfabeten buiten te sluiten van de communicatie. Als je per ongeluk Nederlands praat terwijl je een engelsman in het gezelschap hebt is het echter geen encryptie, het was immers niet je intentie om met iedereen behalve hem te communiceren.

Ik ben het er overigens dus ook niet mee eens dat de ambiguiteit van talen en de vertaling ervan ervoor zorgt dat dit niet als encryptie kan gelden. Encryptie die heel snel/veilig is maar een foutmarge heeft kan nog steeds als encryptie dienen.

[Amanush]

jbdeiman schreef op donderdag 11 juni 2015 @ 08:59:
[...]

Zie reactie hierboven aan emnich: Als je iets om kan zetten naar een versleutelde string en weer terug is het geen encryptie? Volgens mij gaat het wanneer je het juist niet meer (zomaar) om kan zetten eerder om een hash methodiek dan om encryptie.

Je kan het weer terug omzetten, maar bij ROT13 heb je "geen key nodig". Bij ROT echter wel.

ROT13 encryptie? Nee. ROT encryptie? Ja.

Edit: leer het verschil tussen encryption en encoding.

[ Voor 5% gewijzigd door Amanush op 11-06-2015 15:23 ]

[Brent]

Amanush schreef op donderdag 11 juni 2015 @ 15:12:
[...]

Je kan het weer terug omzetten, maar bij ROT13 heb je "geen key nodig". Bij ROT echter wel.

ROT13 encryptie? Nee. ROT encryptie? Ja.

We hebben heel wat mierenneukerij in deze draad gezien, maar ik denk dat we de winnaar gevonden hebben

[Amanush]

Brent schreef op donderdag 11 juni 2015 @ 15:15:
[...]

We hebben heel wat mierenneukerij in deze draad gezien, maar ik denk dat we de winnaar gevonden hebben

Geen sprake van mierenneukerij. Sprake van weten waar je het over hebt.

[Cloud]

Amanush schreef op donderdag 11 juni 2015 @ 15:12:
[...]

ROT13 encryptie? Nee. ROT encryptie? Ja.

Dus een Ceaser cipher is encryptie, zolang de sleutel maar niet 13 is?

[Brent]

Amanush schreef op donderdag 11 juni 2015 @ 15:22:
Vim- en Arch Linux-gebruiker

Geeft niet joh, zat er een beetje in

[mcDavid]

Cloud schreef op donderdag 11 juni 2015 @ 15:25:
[...]

Dus een Ceaser cipher is encryptie, zolang de sleutel maar niet 13 is?

Ik denk dat hij eerder bedoelt: zolang je er niet (expliciet in de naam) bij vermeld wat de sleutel is

[Kwistnix]

In principe, leuk dat men vind dat het geen encryptie is, maar dat is het feitelijk dus wel. Het is gewoon een erg eenvoudig substitution cipher. Het Caesar cipher is toch ook een erkende encryptie methode.

[.oisyn]

Amanush schreef op donderdag 11 juni 2015 @ 15:22:
Sprake van weten waar je het over hebt.

Volgens mij heb jij in het verleden vaak genoeg aangetoond dat dat voor jou niet echt opgaat, meneer de software architect

Maar joking aside, ik zeg nog een keer met klem: lees de reacties en ga erop in. Ga niet stellingen lopen deponeren die al lang en breed de revu zijn gepasseerd, zonder enige argumentatie. Zo voeren we hier geen discussies.

[ Voor 34% gewijzigd door .oisyn op 11-06-2015 15:46 ]

[Amanush]

.oisyn schreef op donderdag 11 juni 2015 @ 15:43:
[...]

Volgens mij heb jij in het verleden vaak genoeg aangetoond dat dat voor jou niet echt opgaat, meneer de software architect

Maar joking aside, ik zeg nog een keer met klem: lees de reacties en ga erop in. Ga niet stellingen lopen deponeren die al lang en breed de revu zijn gepasseerd, zonder enige argumentatie. Zo voeren we hier geen discussies.

Leer eerst maar zelf discusseren in plaats van mensen de grond in te boren op basis van acties van iemand die destijds een stuk jonger was.

Nogal zielig dat je dit soort reacties plaatst.. nouja, had ik ook wel een beetje verwacht van je.

[ Voor 4% gewijzigd door Amanush op 11-06-2015 15:53 ]

[.oisyn]

Goed, blijkbaar kun je niet tegen een grapje. Mea culpa, het was niet rot bedoeld. En niet om 't een of ander, maar dat voorval was een jaar geleden, je was toen 14, dus nu 15 (of net 16), en echt niet dat jij in al die tijd al de benodigde wijsheid hebt vergaard .

Ik stel voor dat we vanaf nu on topic de discussie voortzetten met fatsoenlijke argumenten.

[ Voor 19% gewijzigd door .oisyn op 11-06-2015 15:59 ]

[Laurens-R]

Amanush schreef op donderdag 11 juni 2015 @ 15:50:
[...]

Leer eerst maar zelf discusseren in plaats van mensen de grond in te boren op basis van acties van iemand die destijds een stuk jonger was.

Nogal zielig dat je dit soort reacties plaatst.. nouja, had ik ook wel een beetje verwacht van je.

Met alle respect, maar ik vind dat .oisyn hier gewoon echt gelijk heeft.

De poll score alleen geeft al aan dat het gros van de mensen hier anders denkt over rot13 encryptie dan dat jij dat doet. Nu kan ik zelf ook wel eens koppig zijn... maar als 86% van de mensen (in de poll) hier het over eens is, zou je wellicht toch eens kunnen afvragen hoe dat zich verhoud tot je eigen standpunten.

ontopic: ik zou haast denken dat wat er inmiddels over het onderwerp gezegd kon worden wel gezegd is in het kader van de gestelde vraag. 86% (op het moment van schrijven) vind dat ROT13 encryptie is kunnen we nu weer verder gaan?

[ Voor 13% gewijzigd door Laurens-R op 11-06-2015 16:01 ]

[Cloud]

mcDavid schreef op donderdag 11 juni 2015 @ 15:41:
[...]

Ik denk dat hij eerder bedoelt: zolang je er niet (expliciet in de naam) bij vermeld wat de sleutel is

Dat zou kunnen maar wat doet dat af aan de encryptie? Als je iets encrypt met ROT13 ben je niet verplicht erbij te zetten dat je ROT13 gebruikt hebt. Het valt ook niet te zien aan de tekst (tenzij je gaat analyseren), het is dus geen publieke informatie. Voor een eventuele derde partij, is het gewoon een ROT-encryptie met een onbekende sleutel.

edit:
@hieronder: precies mijn punt

[ Voor 3% gewijzigd door Cloud op 11-06-2015 16:04 ]

[.oisyn]

Scherp . Volgens dezelfde logica is geen enkele encryptie dan encryptie, want je gebruikt altijd een specifieke sleutel.

[ Voor 9% gewijzigd door .oisyn op 11-06-2015 16:02 ]

[Amanush]

Laurens-R schreef op donderdag 11 juni 2015 @ 15:58:
[...]

Met alle respect, maar ik vind dat .oisyn hier gewoon echt gelijk heeft.

De poll score alleen geeft al aan dat het gros van de mensen hier anders denkt over rot13 encryptie dan dat jij dat doet. Nu kan ik zelf ook wel eens koppig zijn... maar als 86% van de mensen (in de poll) hier het over eens is, zou je wellicht toch eens kunnen afvragen hoe dat zich verhoud tot je eigen standpunten.

In sommige gevallen is waar of onwaar wat kort door de bocht. Misschien kunnen we het beter per situatie bekijken.
Ik geloof niet echt in crypto-algoritmes zonder keys.

Cloud schreef op donderdag 11 juni 2015 @ 16:00:
[...]

Dat zou kunnen maar wat doet dat af aan de encryptie? Als je iets encrypt met ROT13 ben je niet verplicht erbij te zetten dat je ROT13 gebruikt hebt. Het valt ook niet te zien aan de tekst (tenzij je gaat analyseren), het is dus geen publieke informatie. Voor een eventuele derde partij, is het gewoon een ROT-encryptie met een onbekende sleutel.

Als je ROT13 gebruikt zonder dat je de key er daadwerkelijk bij vermeld, gebruik je gewoon ROT met '13' als key.

[Kwistnix]

Misschien is het een interessantere discussie of ROT26 wel of geen encryptie is, waarbij de ciphertext "toevallig" gelijk is aan de plain text
Of wordt dat te filosofisch?

[ Voor 9% gewijzigd door Kwistnix op 11-06-2015 16:06 ]

[Amanush]

Kwistnix schreef op donderdag 11 juni 2015 @ 16:05:
Misschien is het een interessantere discussie of ROT26 wel of geen encryptie is, waarbij de ciphertext "toevallig" gelijk is aan de plain text
Of wordt dat te filosofisch?

Als je ROT als 'methode' en ROT1, ROT2, ROT3, [...] ROT24, ROT25, ROT26 als 'algoritme' ziet, ben ik het er overigens wel mee eens dat men ROT13 en ROT26 mag benoemen als 'encryptie-algoritmes'.

[.oisyn]

ROT is een algoritme met 2 inputs: een sleutel en een tekst. ROT_N is hetzelfde algoritme, met N als sleutel.

Er is met geen enkele logica te stellen dat ROT wel encryptie is, maar ROT13 niet meer. Dat ROT13 toevallig een losse functie is in een populaire programmeertaal doet daar verder niets aan af.

[ Voor 20% gewijzigd door .oisyn op 11-06-2015 16:14 ]

[Amanush]

.oisyn schreef op donderdag 11 juni 2015 @ 16:12:

ROT is een algoritme met 2 inputs: een sleutel en een tekst. ROT_N is hetzelfde algoritme, met N als sleutel.

Er is met geen enkele logica te stellen dat ROT wel encryptie is, maar ROT13 niet meer. Dat ROT13 toevallig een losse functie is in een populaire programmeertaal doet daar verder niets aan af.

Als in een populaire taal (bijvoorbeeld: PHP) wel een ROT13-functie beschikbaar is, maar geen ROT-functie, durf ik ROT13 niet echt bepaald meer 'encryptie' noemen, terwijl dat in de theorie misschien wel het geval is.

[Laurens-R]

Amanush schreef op donderdag 11 juni 2015 @ 16:10:
[...]

Als je ROT als 'methode' en ROT1, ROT2, ROT3, [...] ROT24, ROT25, ROT26 als 'algoritme' ziet, ben ik het er overigens wel mee eens dat men ROT13 en ROT26 mag benoemen als 'encryptie-algoritmes'.

ROT is het encryptie algoritme... 1..n is de sleutel.....Wat dat betreft is het niet anders dan andere encryptie methodes... je hebt het encryptie algoritme en een sleutel. Op basis van de sleutel worden er bewerkingen gedaan op de input data. Of dat nou allerlei complexe berekeningen zijn of simpele rotaties, het idee blijft hetzelfde.... de complexiteit is verschillend. Complex of niet complex; het concept blijft hetzelfde.

[Amanush]

Laurens-R schreef op donderdag 11 juni 2015 @ 16:17:
[...]

ROT is het encryptie algoritme... 1..n is de sleutel.....Wat dat betreft is het niet anders dan andere encryptie methodes... je hebt het encryptie algoritme en een sleutel. Op basis van de sleutel worden er bewerkingen gedaan op de input data. Of dat nou allerlei complexe berekeningen zijn of simpele rotaties, het idee blijft hetzelfde.... de complexiteit is verschillend. Complex of niet complex; het concept blijft hetzelfde.

Zoals eerder gezegd: in dat geval is het een encryptie-algoritme.

[.oisyn]

Amanush schreef op donderdag 11 juni 2015 @ 16:16:
[...]

Als in een populaire taal (bijvoorbeeld: PHP) wel een ROT13-functie beschikbaar is, maar geen ROT-functie, durf ik ROT13 niet echt bepaald meer 'encryptie' noemen, terwijl dat in de theorie misschien wel het geval is.

Dus jij beweert dat de classificatie van een algoritme afhangt van de vorm waarin het in een populaire taal geïmplementeerd is?

[Amanush]

.oisyn schreef op donderdag 11 juni 2015 @ 16:20:
[...]


Dus jij beweert dat de classificatie van een algoritme afhangt van de vorm waarin het in een populaire taal geïmplementeerd is?

Zeer onjuist. Ik beweer dat ROT13 praktisch gezien meer geen encryptie te noemen is, maar dat theoretisch gezien wel het geval is.

[begintmeta]

Amanush schreef op donderdag 11 juni 2015 @ 16:21:
...
Zeer onjuist. Ik beweer dat ROT13 praktisch gezien meer geen encryptie te noemen is, maar dat theoretisch gezien wel het geval is.

Waar trek jij die grens?

[.oisyn]

Maar dat geldt dan niet voor ROT5? Want die zit niet in PHP. Dus dat is dan praktisch gezien wel encryptie?

[Laurens-R]

Amanush schreef op donderdag 11 juni 2015 @ 16:21:
[...]

Zeer onjuist. Ik beweer dat ROT13 praktisch gezien meer geen encryptie te noemen is, maar dat theoretisch gezien wel het geval is.

Het feit dat de sleutel vast staat bij ROT13 (want =ROT(13)), maakt het wellicht nog zwakker... maar het blijft encryptie imho.

Volgens mij zijn we het er iig over eens, dat iemand die dit algoritme gebruikt een wapper om z'n oren verdiend.

[Cloud]

Amanush schreef op donderdag 11 juni 2015 @ 16:21:
[...]

Zeer onjuist. Ik beweer dat ROT13 praktisch gezien meer geen encryptie te noemen is, maar dat theoretisch gezien wel het geval is.

En dat was precies wat .oisyn bedoelde, dat is al in het begin van dit topic voorbijgekomen. Het gaat niet om hoeverre de encryptie nog hedendaags bruikbaar is (want inderdaad, waar trek je de grens dan?) Volgens mij gaat het gewoon om de theoretische kant van encryptie.

[Amanush]

.oisyn schreef op donderdag 11 juni 2015 @ 16:23:
Maar dat geldt dan niet voor ROT5? Want die zit niet in PHP. Dus dat is dan praktisch gezien wel encryptie?

Dat is afhankelijk van je standpunt (en/of manier van beredeneren).

Laurens-R schreef op donderdag 11 juni 2015 @ 16:24:
[...]


Het feit dat de sleutel vast staat bij ROT13 (want =ROT(13)), maakt het wellicht nog zwakker... maar het blijft encryptie imho.

Volgens mij zijn we het er iig over eens, dat iemand die dit algoritme gebruikt een wapper om z'n oren verdiend.

Yes, dat zeker.

[Amanush]

Cloud schreef op donderdag 11 juni 2015 @ 16:25:
[...]

En dat was precies wat .oisyn bedoelde, dat is al in het begin van dit topic voorbijgekomen. Het gaat niet om hoeverre de encryptie nog hedendaags bruikbaar is (want inderdaad, waar trek je de grens dan?) Volgens mij gaat het gewoon om de theoretische kant van encryptie.

Als je het vanuit dat punt wil beredeneren moet ik hem gelijk geven.

[.oisyn]

Amanush schreef op donderdag 11 juni 2015 @ 16:25:
[...]

Dat is afhankelijk van je standpunt (en/of manier van beredeneren).

Ja no shit. Alles is afhankelijk van je standpunt en/of manier van beredeneren. Waar ik achter probeer te komen is jouw standpunt.

[Amanush]

.oisyn schreef op donderdag 11 juni 2015 @ 16:27:
[...]


Ja no shit. Alles is afhankelijk van je standpunt en/of manier van beredeneren. Waar ik achter probeer te komen is jouw standpunt.

Mijn standpunt is al duidelijk; ROT13 is een encryptie-algoritme, maar zo noem ik het liever niet.

[begintmeta]

Ik ben dan ook nog steeds benieuwd naar hoe Amanush bepaalt waar de grens moet worden getrokken tussen 'praktisch' wel/geen encryptie.

[ZaZ]

Is een beetje een ROTdiscussie geworden dit

[Amanush]

begintmeta schreef op donderdag 11 juni 2015 @ 16:28:
Ik ben dan ook nog steeds benieuwd naar hoe Amanush bepaalt waar de grens moet worden getrokken tussen praktisch wel/geen encryptie.

Ik denk dat grenzen moeten trekken hier niet van toepassing is. Meer: "grenzen willen trekken".

[ZaZ]

Amanush schreef op donderdag 11 juni 2015 @ 16:28:
[...]

Mijn standpunt is al duidelijk; ROT13 is een encryptie-algoritme, maar zo noem ik het liever niet.

Nee, jij noemt het liever encoding, wat het gewoon niet is.
Da's lekker helder.

[begintmeta]

Amanush schreef op donderdag 11 juni 2015 @ 16:30:
...
Ik denk dat grenzen moeten trekken hier niet van toepassing is. Meer: "grenzen willen trekken".

Goed dan, waarom wil je ze waar trekken?

[ Voor 7% gewijzigd door begintmeta op 11-06-2015 16:32 ]

[Amanush]

begintmeta schreef op donderdag 11 juni 2015 @ 16:31:
[...]

Goed dan, hoe bepaal je waar je ze trekt?

Op het moment waar mensen het slechts implementeren als encoding, noem ik het liever een "grensgeval".

ZaZ schreef op donderdag 11 juni 2015 @ 16:31:
[...]

Nee, jij noemt het liever encoding, wat het gewoon niet is.
[...]

Volgens mij is er niet meer een discussie over of het 'encoding' is.

Amanush schreef op donderdag 11 juni 2015 @ 16:19:
[...]

Zoals eerder gezegd: in dat geval is het een encryptie-algoritme.

[.oisyn]

ZaZ schreef op donderdag 11 juni 2015 @ 16:31:
[...]

Nee, jij noemt het liever encoding, wat het gewoon niet is.

Nou ja, het is wel encoding, maar dat sluit encryptie nog niet uit

[Amanush]

.oisyn schreef op donderdag 11 juni 2015 @ 16:33:
[...]

Nou ja, het is wel encoding, maar dat sluit encryptie nog niet uit

En dan noemen ze mij een mierenneuker.

[Brent]

Amanush schreef op donderdag 11 juni 2015 @ 16:34:
[...]

En dan noemen ze mij een mierenneuker.

Stel je codering en versleuteling nu gelijk?

[.oisyn]

Amanush schreef op donderdag 11 juni 2015 @ 16:34:
[...]

En dan noemen ze mij een mierenneuker.

Als ik stel dat een hond een dier is, maar een dier niet per se een hond, dan vind jij dat mierenneukerij . Het lijkt mij nogal essentieel om te realiseren dat encryptie en encoding niet wederzijds exclusief zijn.

[ Voor 16% gewijzigd door .oisyn op 11-06-2015 16:37 ]

[begintmeta]

Amanush schreef op donderdag 11 juni 2015 @ 16:34:
[...]

En dan noemen ze mij een mierenneuker.

In mijn ogen is het voordehandliggendst dat het om de intentie gaat, op de rest van de wereld kan je namelijk in mindere mate zekerheid hebben,

[Amanush]

Brent schreef op donderdag 11 juni 2015 @ 16:35:
[...]

Stel je codering en versleuteling nu gelijk?

Nee?

.oisyn schreef op donderdag 11 juni 2015 @ 16:36:
[...]


Als ik stel dat een hond een dier is, maar een dier niet per se een hond, dan vind jij dat mierenneukerij

Alle honden zijn dieren. Om erbij te zetten dat het hier om een dier gaat als we het over honden hebben.. tja.

begintmeta schreef op donderdag 11 juni 2015 @ 16:37:
[...]

In mijn ogen is het voordehandliggendst dat het om de intentie gaat, op de rest van de wereld kan je namelijk in mindere mate zekerheid hebben,

Mee eens.

Om mijn mening even wat duidelijker te verwoorden:
- ROT13 is encryptie
- ROT13 wordt gebruikt vaak niet gebruikt als encryptie, maar slechts voor encoding.
- Ik vind het riskant om ROT13 tot encryptie-algoritme of encoding-algoritme te benoemen

[ZaZ]

.oisyn schreef op donderdag 11 juni 2015 @ 16:33:
[...]
Nou ja, het is wel encoding, maar dat sluit encryptie nog niet uit

Als je encoding heel technisch interpreteert wel. Encoding heeft alleen volgens mij nooit als doel om data 'moeilijker' te lezen te maken. ROT heeft wel dat doel en hoewel het een redelijk shitty algoritme is, is het het wel, want het heeft dat doel.

[jbdeiman]

Amanush schreef op donderdag 11 juni 2015 @ 15:12:
[...]

Je kan het weer terug omzetten, maar bij ROT13 heb je "geen key nodig". Bij ROT echter wel.

ROT13 encryptie? Nee. ROT encryptie? Ja.

Edit: leer het verschil tussen encryption en encoding.

Oh ik ken het verschil wel:
- Rot(13) doet hetzelfde als rot13()

Rot(13) is wel encryptie en rot13() niet volgens jou, echter vergeet je voor het gemak dan maar dat je (normaal gesproken!) niet zomaar aan de buitenwereld aangeeft dat je rot13 gebruikt. Men ziet alleen dat er een (vorm van) versleuteling is toegepast, niet welke dat is.
Degene die het moet kunnen lezen geef je aan dat het rot13 (of rot(13) ) is, maakt voor de ontvanger echt niet uit.

[Laurens-R]

ZaZ schreef op donderdag 11 juni 2015 @ 16:40:
[...]
Als je encoding heel technisch interpreteert wel. Encoding heeft alleen volgens mij nooit als doel om data 'moeilijker' te lezen te maken. ROT heeft wel dat doel en hoewel het een redelijk shitty algoritme is, is het het wel, want het heeft dat doel.

Hoewel encoding het ook niet altijd makkelijker maakt... misschien wel geschikter voor een bepaald doel. Voorbeeld Base64 maakt tekst nou niet leesbaarder (integendeel zelfs), wel geschikter om bijvoorbeeld via een GET/POST request mee te geven.

[ Voor 12% gewijzigd door Laurens-R op 11-06-2015 16:44 ]

[Amanush]

jbdeiman schreef op donderdag 11 juni 2015 @ 16:41:
[...] Rot(13) is wel encryptie en rot13() niet volgens jou, [...]

Onjuist. Lees mijn posts.

ROT13 is encryptie, maar zo wil ik het liever niet noemen.

[ Voor 13% gewijzigd door Amanush op 11-06-2015 16:46 ]

[.oisyn]

Amanush schreef op donderdag 11 juni 2015 @ 16:38:
Alle honden zijn dieren. Om erbij te zetten dat het hier om een dier gaat als we het over honden hebben.. tja.

Dat is niet hoe de discussie verliep. Er werd gesteld dat als iets een hond (encryptie) is, dat het dan geen dier (encoding) is. ZaZ zegt dat jij beweert dat het een dier (encoding) is, "wat het gewoon niet is". Maar je komt er niet omheen dat ROT(n) een vorm van encoding is. Maar zeggen dat iets een encoding is sluit niet uit dat het een encryptie is. Om met je eigen woorden te spreken:

Amanush schreef op donderdag 11 juni 2015 @ 15:12:
Edit: leer het verschil tussen encryption en encoding.

Het lijkt me een te fundamentele terminologie om dit af te doen als mierenneukerij. Zeker door iemand die al eerder anderen maande het verschil tussen beide begrippen te leren kennen.

[ZaZ]

Laurens-R schreef op donderdag 11 juni 2015 @ 16:42:
[...]


Hoewel encoding het ook niet altijd makkelijker maakt... misschien wel geschikter voor een bepaald doel. Voorbeeld Base64 maakt tekst nou niet leesbaarder (integendeel zelfs), wel geschikter om bijvoorbeeld via een GET/POST request mee te geven.

Aanhalen dat het het moeilijker maakt en daarmee dus wel iets dichterbij encryptie brengt is een beetje een drogredenering.

[Laurens-R]

ZaZ schreef op donderdag 11 juni 2015 @ 16:47:
[...]

Aanhalen dat het het moeilijker maakt en daarmee dus wel iets dichterbij encryptie brengt is een beetje een drogredenering.

Dat was dan ook niet m'n redenering... nergens heb ik gezegd dat het dan meer in de buurt van encryptie komt. Het was meer bedoeld als een extra denkslag op de gedachte die de quote aanhaalde.

[ Voor 21% gewijzigd door Laurens-R op 11-06-2015 16:51 ]

[Amanush]

.oisyn schreef op donderdag 11 juni 2015 @ 16:46:
[...]

Dat is niet hoe de discussie verliep. Er werd gesteld dat als iets een hond (encryptie) is, dat het dan geen dier (encoding) is. ZaZ zegt dat jij beweert dat het een dier (encoding) is, "wat het gewoon niet is". Maar je komt er niet omheen dat ROT(n) een vorm van encoding is. Maar zeggen dat iets een encoding is sluit niet uit dat het een encryptie is. Om met je eigen woorden te spreken:

[...]


Het lijkt me een te fundamentele terminologie om dit af te doen als mierenneukerij. Zeker door iemand die al eerder anderen maande het verschil tussen beide begrippen te kennen.

Kan zijn dat ik eens een keer `niet` of `geen` heb gezegd, maar `niet slechts` bedoelde.

[.oisyn]

Argh, het ging niet om een post van jou maar om een post van ZaZ... Ach laat ook maar

[Amanush]

.oisyn schreef op donderdag 11 juni 2015 @ 16:50:
Argh, het ging niet om een post van jou maar om een post van ZaZ... Ach laat ook maar

Oh, haha, mijn excuses.

[ZaZ]

Laurens-R schreef op donderdag 11 juni 2015 @ 16:48:
[...]
Dat was dan ook niet m'n redenering... nergens heb ik gezegd dat dat het dan encryptie maakt. Het was meer een extra slag op de gedachte die ik in de quote aanhaalde.

Ok, bedoelde het ook niet als aanval hoor
In geval van Base64 zie ik het nog steeds als encoding. Dat algoritme heeft puur als doel om data om te zetten in printbare karakters en doet er niets aan om het bewust moeilijker te maken om de data weer terug te halen. Op het moment dat een encoding (nou je zin .oisyn? ) dat wel doet is het encryptie.
Of de bedenker van het algoritme nou een sterk algoritme ervoor heeft bedacht lijkt me van onderschikt belang. Het doel was het het versleutelen, dus het is encryptie.

[Laurens-R]

kunnen we inmiddels een conclusie vormen?

heb het idee dat we af en toe verzanden in herhaling (met gebruik van andere woorden voor hetzelfde punt)...

of mis ik nou de grote existentiële vraag die we hier proberen te beantwoorden?

[ Voor 80% gewijzigd door Laurens-R op 11-06-2015 17:05 ]

[ZaZ]

Ja, bij dit soort vragen gewoon kijken op Wikipedia.
Scheelt een hoop gedoe.

Rot13 is een simpel encryptiealgoritme.

[Laurens-R]

ZaZ schreef op donderdag 11 juni 2015 @ 17:04:
Ja, bij dit soort vragen gewoon kijken op Wikipedia.
Scheelt een hoop gedoe.


[...]

Ik zeg slot er op

[.oisyn]

Laurens-R schreef op donderdag 11 juni 2015 @ 17:02:
heb het idee dat we af en toe verzanden in herhaling (met gebruik van andere woorden voor hetzelfde punt)...

We houden gewoon steeds dezelfde discussie, maar dan met steeds een andere encryptiesleutel

[Laurens-R]

.oisyn schreef op donderdag 11 juni 2015 @ 17:16:
[...]

We houden gewoon steeds dezelfde discussie, maar dan met steeds een andere encryptiesleutel

Ik ga hier spijt van krijgen : volgens mij hebben we het dan over encoding, want het is nog steeds helder wat je bedoeld; alleen de presentatie van de discussie wijzigt.

... aan de andere kant... het verloop van de discussie werd er ook niet duidelijker van af en toe

[ Voor 14% gewijzigd door Laurens-R op 11-06-2015 17:36 ]

[gekkie]

Hmm mag ik dan net voor het slotje nog vragen hoe de meningen over dubbel-rot-13 zijn ? )

[incaz]

Amanush schreef op donderdag 11 juni 2015 @ 16:28:
[...]

Mijn standpunt is al duidelijk; ROT13 is een encryptie-algoritme, maar zo noem ik het liever niet.

'Duidelijk' zou niet het eerste woord zijn wat in me opkomt bij jouw omschrijving

[mcDavid]

.oisyn schreef op donderdag 11 juni 2015 @ 16:01:
Scherp . Volgens dezelfde logica is geen enkele encryptie dan encryptie, want je gebruikt altijd een specifieke sleutel.

Een groot verschil is wel dat bij rot13 (en meer van dat soort simpele encodings, denk ASCII, Duits, morse, etc) de sleutel niet geheim is, en bovendien gemakkelijk te achterhalen is dmv analyseren van het bericht.

Dat is wat mij betreft een belangrijk verschil, los van de woordenboek definities.

Edit: overigens voel ik ook wel iets voor de stelling dat het afhankelijk is van het gebruiksdoel.

[ Voor 35% gewijzigd door mcDavid op 11-06-2015 19:08 ]

[Cloud]

mcDavid schreef op donderdag 11 juni 2015 @ 19:02:
[...]

Een groot verschil is wel dat bij rot13 (en meer van dat soort simpele encodings, denk ASCII, Duits, morse, etc) de sleutel niet geheim is, en bovendien gemakkelijk te achterhalen is dmv analyseren van het bericht.

Waarom is de sleutel niet geheim bij ROT13? Als jij daarmee een bericht versleutelt, vermeld je dan los bij het bericht dat het om ROT13 gaat?

[mcDavid]

Cloud schreef op donderdag 11 juni 2015 @ 20:13:
[...]

Waarom is de sleutel niet geheim bij ROT13? Als jij daarmee een bericht versleutelt, vermeld je dan los bij het bericht dat het om ROT13 gaat?

Dit kan eenvoudig worden afgeleid uit het analyseren van het versleutelde bericht. Dat is een groot verschil met encryptiemechanismen zoals AES, die er specifiek op gebouwd zijn dat de sleutel op geen enkele manier te achterhalen is, behalve bruteforcen.

Maar je brengt me wel op een idee voor een andere interessante stelling:
Encoding is encryptie als het bekendmaken van het gebruikte mechanisme, niet genoeg is om het bericht te ontsleutelen.

[gekkie]

Enige verschil tussen ROT en AES als algoritme is dat het bruteforcen van de sleutel bij de ene een tikkie sneller resultaat opleverd dan bij het andere. Dus als de duur van het bruteforcen de maatgevende factor zou moeten zijn .. hoe zou je deze willen kwantificeren en waar ligt de grens ?

[johnkeates]

Het werd vroeger als encryptie gezien om dat de 'sleutel' het aantal verplaatsingen was. Tegenwoordig niet meer om dat met de huidige rekenkracht het aantal rotaties/substituties niet meer uit maakt om dat je met een simpele analyse elke versie kan 'kraken', waarbij in veel gevallen het kraken identiek is aan normale decodering.

Stel dat je niet weet hoe veel posities een karakter moet verschuiven, dan probeer je ze gewoon allemaal uit, vroeg of laat kom je toch wel bij de juiste.

ROT13 kan je net als base64 onder encoding en niet encryption.

gekkie schreef op donderdag 11 juni 2015 @ 20:38:
Enige verschil tussen ROT en AES als algoritme is dat het bruteforcen van de sleutel bij de ene een tikkie sneller resultaat opleverd dan bij het andere. Dus als de duur van het bruteforcen de maatgevende factor zou moeten zijn .. hoe zou je deze willen kwantificeren en waar ligt de grens ?

Je kan in principe alles encryptie kunnen noemen, ook ASCII of UTF-8. Of het inzetbaar is kan je net als alle andere vormen afleiden aan de tijd die je nodig zou hebben om het te kraken. Als ROT op basis van verschuiven van het alphabet werkt van A tot Z, dan heb je maar 26 mogelijke 'sleutels', niet iets wat je veilig kan noemen gezien de tijd die het eist om te 'kraken' verwaarloosbaar is.

Je kan ook stellen dat een onveranderde tekst encryptie is om dat je letters in ASCII uitdrukt. Het leesbaar maken vergt 0 'kraak'-cycli en kan je dus ook niet bepaald als 'gecodeerd' beschouwen.

Als je als voorbeeld neemt dat je 10000 'combinaties' per seconde kan uitproberen om iets te ontsleutelen kan je stellen dat alles wat 10000 combinaties of minder heeft niet als zinvolle versleuteling gezien kan worden. Nu is die 10000 uit de lucht gegrepen, maar hang daar een accuraat getal in voor je algoritme naar keuze en je weet in hoeverre iets als versleuteld gezien kan worden.

[ Voor 59% gewijzigd door johnkeates op 11-06-2015 20:47 ]

[mcDavid]

gekkie schreef op donderdag 11 juni 2015 @ 20:38:
Enige verschil tussen ROT en AES als algoritme is dat het bruteforcen van de sleutel bij de ene een tikkie sneller resultaat opleverd dan bij het andere. Dus als de duur van het bruteforcen de maatgevende factor zou moeten zijn .. hoe zou je deze willen kwantificeren en waar ligt de grens ?

Nee dat is niet waar. Een ceasar cipher heeft geen enkel mechanisme om te voorkomen dat de sleutel gerevese-engineered wordt. Wellicht is het in het geval van ROT inderdaad makkelijker om te bruteforcen, maar ook als je andere character replacing of zelfs behoorlijk veel ingewikkelder encoding mechanismes gebruikt, is het mogelijk door analyse van de tekst de sleutel te reverse-engineeren.
Bij AES etc. is dit (voor zover bekend) niet mogelijk.

[Megamind]

johnkeates schreef op donderdag 11 juni 2015 @ 20:40:
Het werd vroeger als encryptie gezien om dat de 'sleutel' het aantal verplaatsingen was. Tegenwoordig niet meer om dat met de huidige rekenkracht het aantal rotaties/substituties niet meer uit maakt om dat je met een simpele analyse elke versie kan 'kraken', waarbij in veel gevallen het kraken identiek is aan normale decodering.

Stel dat je niet weet hoe veel posities een karakter moet verschuiven, dan probeer je ze gewoon allemaal uit, vroeg of laat kom je toch wel bij de juiste.

ROT13 kan je net als base64 onder encoding en niet encryption.


[...]


Je kan in principe alles encryptie kunnen noemen, ook ASCII of UTF-8. Of het inzetbaar is kan je net als alle andere vormen afleiden aan de tijd die je nodig zou hebben om het te kraken. Als ROT op basis van verschuiven van het alphabet werkt van A tot Z, dan heb je maar 26 mogelijke 'sleutels', niet iets wat je veilig kan noemen gezien de tijd die het eist om te 'kraken' verwaarloosbaar is.

Wacht, dus AES is over 100 jaar dan ook encoding geworden? Blijkbaar is er dan ergens een omslagpunt.

[johnkeates]

Megamind schreef op donderdag 11 juni 2015 @ 20:46:
[...]

Wacht, dus AES is over 100 jaar dan ook encoding geworden? Blijkbaar is er dan ergens een omslagpunt.

Ja, als je het in een paar seconden leesbaar kan maken is het moeilijk als 'versleuteld' te beschouwen. Versleuteling is niet zo zwart-wit dat iets instant te kraken is of onmogelijk te kraken is, je kan er hoogstens een tijdsduur aan geven. Dat is in de praktijk geen probleem als je bijvoorbeeld uit kan rekenen dat een bepaalde methode 20000 jaar zou kosten om te kraken, en de informatie na 100 jaar al waardeloos is.

[gekkie]

mcDavid schreef op donderdag 11 juni 2015 @ 20:43:
[...]

Nee dat is niet waar. Een ceasar cipher heeft geen enkel mechanisme om te voorkomen dat de sleutel gerevese-engineered wordt. Wellicht is het in het geval van ROT inderdaad makkelijker om te bruteforcen, maar ook als je andere character replacing of zelfs behoorlijk veel ingewikkelder encoding mechanismes gebruikt, is het mogelijk door analyse van de tekst de sleutel te reverse-engineeren.
Bij AES etc. is dit (voor zover bekend) niet mogelijk.

Owwwwkee .. testje:

hyuyhwltzWYSws

Doe mij de originele tekst en de sleutel ... doormiddel van analyse ... zou een eitje moeten zijn naar ik begreep.

[ Voor 4% gewijzigd door gekkie op 11-06-2015 20:54 ]

[mcDavid]

gekkie schreef op donderdag 11 juni 2015 @ 20:50:
[...]

Owwwwkee .. testje:

hyuyhwltzWYSws

Doe mij de originele tekst en de sleutel ...

Ik heb nergens beweerd dat ik zelf een crypto-analist ben die datsoort dingen uit zijn mouw schudt, ik zeg enkel dat het mogelijk is.

Als leuk voorbeeld kun je de Enigma code nemen. Knappe koppen waren tijdens WOII in Engeland soms dagen bezig om d.m.v. patroonherkenning en bekende zwakheden in de enigma-machine, van één bericht de sleutel te reverse-engineeren zodat die sleutel gebruikt kon worden om weer heel veel andere berichten te ontcijferen. Geen idee hoe ze dat deden, maar het lukte ze wel. Tot ze op een gegeven moment machines hadden om de code te bruteforcen, toen was dat niet meer nodig. Maar omdat de mogelijkheid bestond de sleutel te reverse engineeren kun je dus stellen dat enigma geen encryptie maar encoding was. Had Hitler het maar geweten

[ Voor 3% gewijzigd door mcDavid op 11-06-2015 21:02 ]

[HollowGamer]

Voor mij hoeft het topic niet echt opslot.
Ik heb zo'n beetje alle reacties gelezen, en kom toch wel aardige stof tegen (o.a. hoe en wat vragen/opzet van..). Zie ook daarop weer reacties komen.

De conclusie is voor ieder anders, maar ik zie wel een (erg grote) meerderheid de vraag met 'Eens' beantwoorden. Ook Wiki is inderdaad daar over eens.

Het topic zou bijvoorbeeld ook over andere encryptie/decode ontwerpen kunnen gaan (wat ook weldegelijk gebeurt en interessant is), maar dan wordt het misschien een warboel.

Anyway, thanks voor de reply's, weer wat geleerd.

[ Voor 4% gewijzigd door HollowGamer op 11-06-2015 23:17 ]

[begintmeta]

mcDavid schreef op donderdag 11 juni 2015 @ 20:43:
...
Bij AES etc. is dit (voor zover bekend) niet mogelijk.

Volgens mij is het alleen praktisch niet mogelijk, zie ook Biclique Cryptanalysis of the Full AES^PDF van Bogdanov, Khovratovich en Rechberger en ook bijvoorbeeld aanvallen om versleutelde data van random data te onderscheiden zijn mogelijk

Is alleen gebruik van een otp encryptie?

[jbdeiman]

Amanush schreef op donderdag 11 juni 2015 @ 16:43:
[...]

Onjuist. Lees mijn posts.

ROT13 is encryptie, maar zo wil ik het liever niet noemen.

Als je ziet wat ik van je gequote heb (je oorspronkelijke post) kan je me denk ik niet kwalijk nemen dat ik daar uithaalde dat je vond dat ROT13 geen encryptie is, maar ROT(x) wel.

Daar reageerde ik ook op niet op de aangepaste of later geplaatste post. Het is lastig je eigenlijke mening te lezen als je in de ene post echt letterlijk zegt dat het geen encryptie is maar eigenlijk vindt dat het wel encryptie is, maar de naam niet verdient.

[Cloud]

mcDavid schreef op donderdag 11 juni 2015 @ 20:29:
[...]

Dit kan eenvoudig worden afgeleid uit het analyseren van het versleutelde bericht.

Dat de sleutel eenvoudig te achterhalen is middels bruteforce, is wat anders dan 'de sleutel is niet geheim'. Je noemde ze zelf ook al als gescheiden zaken, ga ze dan niet door elkaar gebruiken. Nogmaals, het gaat hier vooral om de theorie niet om hoe praktisch toepasbaar een algoritme is, alvorens het encryptie genoemd kan worden. Want dat is echt een héél andere discussie. Iedereen is het er denk ik wel over eens dat nu ROT(13) daadwerkelijk inzetten als encryptie, oliedom is.

mcDavid schreef op donderdag 11 juni 2015 @ 20:58:
[...]
Maar omdat de mogelijkheid bestond de sleutel te reverse engineeren kun je dus stellen dat enigma geen encryptie maar encoding was.

Dat is echt een hele rare stelling. Dus alle encryptie waarvan de sleutel te achterhalen is, is slechts encoding? Misschien bij jouw definitie van encryptie maar zoals we reeds gezien hebben, delen erg weinig mensen die mening met je.

begintmeta schreef op vrijdag 12 juni 2015 @ 09:00:
[...]
Is alleen gebruik van een otp encryptie?

Volgens de interpretatie van mcDavid wel.

offtopic:
Verder lijkt dit topic ook wel een beetje op een ROT-discussie, want we lijken in cirkels rond te lopen qua argumentatie

[ Voor 3% gewijzigd door Cloud op 12-06-2015 09:52 ]

[mcDavid]

Cloud schreef op vrijdag 12 juni 2015 @ 09:39:
[...]

Dat de sleutel eenvoudig te achterhalen is middels bruteforce, is wat anders dan 'de sleutel is niet geheim'. Je noemde ze zelf ook al als gescheiden zaken, ga ze dan niet door elkaar gebruiken. Nogmaals, het gaat hier vooral om de theorie niet om hoe praktisch toepasbaar een algoritme is, alvorens het encryptie genoemd kan worden. Want dat is echt een héél andere discussie. Iedereen is het er denk ik wel over eens dat nu ROT(13) daadwerkelijk inzetten als encryptie, oliedom is.

Dat bedoel ik niet. Bruteforcen is iets anders dan de sleutel afleiden uit het encoded bericht.
Tevens, bij gebruik van rot13 is de sleutel idd bekend, aangezien dit een algemeen gebruikte sleutel is. Vergelijkbaar met een ASCII tabel of morse codeboek. Bij een morse boodschap wordt ook niet eerst de sleutel gedeeld, maar omdat die tot het publieke domein behoort noemen we morse geen encryptie.

En die theorie, daar gaan we hier sowieso al aan voorbij. Als het doel van dit topic was de woordenboek definitie van het woord encryptie op te zoeken was er sowieso geen discussie aan.

[...]

Dat is echt een hele rare stelling. Dus alle encryptie waarvan de sleutel te achterhalen is, is slechts encoding? Misschien bij jouw definitie van encryptie maar zoals we reeds gezien hebben, delen erg weinig mensen die mening met je.

Dat kun je wat mij betreft best stellen ja. Zodra een zwakheid gevonden en gepubliceerd is, sta je niet bepaald sterk meer als je wilt hard maken dat je er alles aan gedaan hebt je bericht voor buitenstaanders onleesbaar te maken.

[Cloud]

mcDavid schreef op vrijdag 12 juni 2015 @ 10:15:
[...]
Tevens, bij gebruik van rot13 is de sleutel idd bekend, aangezien dit een algemeen gebruikte sleutel is. Vergelijkbaar met een ASCII tabel of morse codeboek.

Nogmaals, zo werkt dat niet. Zie: Cloud in "[Disc] ROT13, encryptie of niet?".

ASCII/morse hierbij meenemen is echt appels en peren vergelijken. Beide zijn uiteraard geen encryptie, want beide kennen geen verschillende (laat staan onbekende) sleutels; ROT(n) wel al zijn het er nog zo weinig.

[...]

Dat kun je wat mij betreft best stellen ja. Zodra een zwakheid gevonden en gepubliceerd is, sta je niet bepaald sterk meer als je wilt hard maken dat je er alles aan gedaan hebt je bericht voor buitenstaanders onleesbaar te maken.

Hoewel je daar gelijk in hebt, is dat héél wat anders dan stellen dat de gebruikte techniek ineens geen encryptie meer is. Een techniek is (slechte) encryptie of is dat niet. Maar goed, die discussie is óók al gevoerd en ga ik niet nog een keer doen.

[jbdeiman]

mcDavid schreef op vrijdag 12 juni 2015 @ 10:15:
[...]

Dat bedoel ik niet. Bruteforcen is iets anders dan de sleutel afleiden uit het encoded bericht.
Tevens, bij gebruik van rot13 is de sleutel idd bekend, aangezien dit een algemeen gebruikte sleutel is. Vergelijkbaar met een ASCII tabel of morse codeboek. Bij een morse boodschap wordt ook niet eerst de sleutel gedeeld, maar omdat die tot het publieke domein behoort noemen we morse geen encryptie.

En die theorie, daar gaan we hier sowieso al aan voorbij. Als het doel van dit topic was de woordenboek definitie van het woord encryptie op te zoeken was er sowieso geen discussie aan.

Bij ROT 13 is de sleutel bekend bij het decrypten, maar niet bij het bericht zelf. Als het goed is bij de ontvanger (degene die het bericht moet ontsleutelen) wel een sleutel bekend, maar stuur je niet mee dat het ROT13 is. Zeggen dat bij ROT13 de code algemeen bekend is geldt inderdaad bij het versleutelen zelf, maar niet wanneer je het geëncodeerde bericht in handen krijgt.

Zie dit bijvoorbeeld:

Qrmr grxfg vf zrg fge ebg qregvra orjrexg, znne mvr wvw qr fyrhgry nna urg orevpug

Als ik jou niet zeg dat het met rot13 is bewerkt (immers jij bent de ontvanger niet), dan lijkt het een bijzondere tekst en zie je niet eens dat het rot13 is. Ben jij wel de ontvanger dan geef ik aan waarmee (hoe) ik het heb versleuteld en je kan het weer leesbaar maken.
Wat je (en dat is een zwakte van deze versleuteling) vrij snel door kan hebben is dat er een redelijk logische zins + woordstructuur lijkt te staan, al zijn de woorden niet erg logisch. Je kan dus vrij eenvoudig gokken dat het om een ROT algoritme gaat en hebt dan maar "x" sleutels om te proberen, je weet op dat moment de sleutel echter niet.

Dan staat er:

Deze tekst is met str rot dertien bewerkt, maar zie jij de sleutel aan het bericht

Dat zou hetzeflde zijn als dat je precies meegeeft bij een versleuteld bericht wat de gebruikte encoderingsmethode + de sleutel is, dan kan iedere ontvanger dit ook weer ontsleutelen, omdat bijgevoegd is hoe die is versleuteld.

ROT13 is niets anders dan een functie die een bepaald algoritme toepast waarbij de sleutel 13 is en is daarmee niet wezenlijk anders dan wat voor methode ook:
- Het gaat altijd om een encryptie methode en een sleutel, waarbij de andere kant (ontvanger) als enige te weten moet krijgen om welke methode + welke sleutel het gaat.

Zonder methode (slot), maar met alleen een sleutel kan je een huis niet in, je hebt ze beiden nodig. Je moet weten waar de sleutel in moet om hem toe te kunnen passen.

[ Voor 8% gewijzigd door jbdeiman op 12-06-2015 11:03 ]

[bwerg]

Mijn duit, die nu het zakje in gaat:
Er zijn een aantal eisen aan encryptie: de enige die echt objectief te meten is is dat decryptie naar het origineel mogelijk is.
Een aantal andere eisen zijn minder eenduidig: de versleuteling moet niet of moeilijk te lezen zijn. De identiteits-functie lijkt me de enige functie die echt objectief verworpen kan worden voor deze eis: als je het leest kun je niet eens zien dat het versleutelt is, dus het is sowieso niet moeilijker te lezen dan het origineel. Voor alle andere functies is het een kwestie van context en van hoe hoog je de lat legt. De lat ligt bij rot13 heel laag maar het is een lat.
Dan verder nog een paar andere eisen zoals performance, maar die zijn niet relevant.

Ik heb de rest van het topic niet gelezen, en dit was ook mijn gehele bijdrage. Doei.

[ Voor 3% gewijzigd door bwerg op 12-06-2015 11:59 ]

[Soundless]

Ik kom er ook even bij.

Zijn er nog steeds mensen die van mening zijn dat Duits encryptie is? Zo ja, kun je dan niet beter alles een 'taal' noemen. Dus ROT13 is een taal.

Scheelt weer een hoop

[Gerco]

Soundless schreef op maandag 15 juni 2015 @ 14:09:
... Zo ja, kun je dan niet beter alles een 'taal' noemen. Dus ROT13 is een taal.

Dat lijkt me onzin. Encryptie is enkel een transformatie van een input naar een output die "moeilijk" om te draaien hoort te zijn. Je kan met enkel rot13 (of AES) niets beschrijven, het heeft geen betekenis van zichzelf, en is dus geen taal.

[Soundless]

Gerco schreef op maandag 15 juni 2015 @ 14:47:
[...]

Dat lijkt me onzin. Encryptie is enkel een transformatie van een input naar een output die "moeilijk" om te draaien hoort te zijn. Je kan met enkel rot13 (of AES) niets beschrijven, het heeft geen betekenis van zichzelf, en is dus geen taal.

Juist. En bekijk het nu andersom. Hoe kun je met die beredenering nou vinden dat Duits dan een encryptie is?

[Onbekend]

Hier mijn mening op: ROT13 is een encryptie, maar een zeer zwakke vorm.
Het is het zelfde als iedereen met een AES256-encryptie altijd de zelfde sleutel gebruikt.

Een encryptie is pas goed dat als je eenmaal weet welke codering er is gebruikt, je alsnog niets kunt ontcijferen zonder de sleutel er bij te hebben.

[ Voor 7% gewijzigd door Onbekend op 15-06-2015 19:58 ]

[bwerg]

Soundless schreef op maandag 15 juni 2015 @ 15:58:
[...]

Juist. En bekijk het nu andersom. Hoe kun je met die beredenering nou vinden dat Duits dan een encryptie is?

Omdat je een Nederlandse tekst naar Duits kan transformeren, en terug, en dat het voor iemand die geen Duits spreekt onleesbaar is. Dat zijn de eisen voor encryptie.

Al zijn natuurlijke talen niet één op één vertaalbaar en krijg je dus doorgaans je origineel niet terug, dus daarom is het strikt genomen geen inverteerbare transformatie. Probeer maar eens iets door google translate te halen, en het resultaat nog een keer maar dan in omgekeerde richting.

[begintmeta]

Onbekend schreef op maandag 15 juni 2015 @ 19:57:
...
Een encryptie is pas goed dat als je eenmaal weet welke codering er is gebruikt, je alsnog niets kunt ontcijferen zonder de sleutel er bij te hebben.

Inderdaad, Kerckhoffs' principes, een Limburgse bijdrage naar het schijnt,

[ Voor 6% gewijzigd door begintmeta op 15-06-2015 23:46 ]

[bwerg]

Desondanks ís encryptie zonder key wel encryptie.

[begintmeta]

bwerg schreef op dinsdag 16 juni 2015 @ 08:18:
Desondanks ís encryptie zonder key wel encryptie.

Encryptie zonder key? Er is altijd een sleutel, naast een algoritme toch? Of misschien zou je eerder kunnen zeggen dat er een hele hoop (groepen) algoritmes zijn (het algoritme is altijd de sleutel), met de 'keys' als 'intragroepsidentificator' en het 'algoritme' als 'intergroepsidentificator'.

[ Voor 29% gewijzigd door begintmeta op 16-06-2015 09:30 ]

[bwerg]

In de praktijk wel, ja, en er is natuurlijk altijd wel een parameter dat als key kan dienen, maar dat is niet een vereiste. Ten minste, als je lat heel laag ligt.

Volgens het kerckhoffs-principe moet het algoritme niet de sleutel zijn omdat het algoritme bekend moet kunnen zijn, een sleutel niet.

Maar goed, dat is allemaal gemierenneuk want je kan er in de praktijk toch niks serieus mee. Behalve briefjes in de klas onleesbaar maken voor de docent of zo.

[SKiLLa]

Die details zijn anders verdomde significant hoor; zou het niet gemierenneuk willen noemen. Crypto staat of valt met de details. Denk even aan AES-CBC vs AES-ECB, 9 van de 10 non-crypto nerds lezen: AES --> is goed, klaar. Totdat ze de ECB-Tux foto gezien hebben:)

En ROT13 mag dan formeel wel een encryptie-algoritme zijn, ik noem het altijd denigrerend obfuscatie. Mooiste fail voorbeeld van encoding vs encryptie vind ik deze: wachtwoorden met utf-8 versleuteld