[Disc] ROT13, encryptie of niet?

[HollowGamer]

Deze discussie is afgesplitst vanuit [alg] Slechtste programmeervoorbeelden deel 5

gekkie schreef op zaterdag 30 mei 2015 @ 13:27:
[...]

Daarom zweer ik zelf dan ook altijd bij rot-13 voor encryptie .. hell voor de extra veiligheid maak ik er meestal nog dubbel rot-13 van

PHP:

$=str_rot13(str_rot13($v))

Maar str_rot13 is eigenlijk geen encryptie, meer een manier om strings wat 'kleiner' te maken.

Ik vind het wel jammer dat md5/sha1 een slechte naam hebben gekregen, voor sommige gebruik is het nog steeds wel handig (zoals checken of je bestanden compleet zijn binnengekomen).

[ Voor 15% gewijzigd door .oisyn op 10-06-2015 13:53 ]

[Ethernal Five]

HollowGamer schreef op zondag 07 juni 2015 @ 22:22:
[...]



Maar str_rot13 is eigenlijk geen encryptie, meer een manier om strings wat 'kleiner' te maken.

Ik vind het wel jammer dat md5/sha1 een slechte naam hebben gekregen, voor sommige gebruik is het nog steeds wel handig (zoals checken of je bestanden compleet zijn binnengekomen).

rot13 is ook geen manier om een string kleiner te maken, maar om de string niet direct leesbaar te maken. Het enigste wat het doet is de letters 13 characters naar rechts schuiven.

Ook is het helemaal niet verkeerd om md5 te gebruiken voor file hashes zoals jij aangeeft, als je het maar niet voor wachtwoorden gebruikt

[HollowGamer]

Ethernal Five schreef op zondag 07 juni 2015 @ 22:26:
[...]


rot13 is ook geen manier om een string kleiner te maken, maar om de string niet direct leesbaar te maken. Het enigste wat het doet is de letters 13 characters naar rechts schuiven.

Ook is het helemaal niet verkeerd om md5 te gebruiken voor file hashes zoals jij aangeeft, als je het maar niet voor wachtwoorden gebruikt

Je hebt helemaal gelijk over rot13, over rtfm gesproken.

Same voor sha1, het is al jaren bekend maar wordt zo als aangegeven toch nog steeds gebruikt.

[Firesphere]

HollowGamer schreef op zondag 07 juni 2015 @ 22:22:
[...]



Maar str_rot13 is eigenlijk geen encryptie, meer een manier om strings wat 'kleiner' te maken.

Ik vind het wel jammer dat md5/sha1 een slechte naam hebben gekregen, voor sommige gebruik is het nog steeds wel handig (zoals checken of je bestanden compleet zijn binnengekomen).

Errrrr, wut?

[bwerg]

Ethernal Five schreef op zondag 07 juni 2015 @ 22:26:
[...]


rot13 is ook geen manier om een string kleiner te maken, maar om de string niet direct leesbaar te maken. Het enigste wat het doet is de letters 13 characters naar rechts schuiven.

Maar dan wel alleen voor de standaard 52 latijnse letters (upper- en lowercase). Als het ook op andere letters/cijfers/tekens zou werken zou het wel héél geavanceerd zijn.

Het enige nut van rot13 is een beetje lolbroekerij en de eerste 'kraak de code'-opdracht voor dummies.

[kenneth]

Hmm, rot13 had wel degelijk nut hoor. Mogelijk aanstootgevende teksten (of antwoorden op raadsels) zijn daarmee niet gelijk zichtbaar voor de nietsvermoedende lezer. Een spoilertag uit het usenet-tijdperk dus:

Pas op, heftige bierdiscussie! Vx ivaq Tebyfpu avrg yrxxre.

Door iedereen te ontcijferen maar mensen die geen zin hebben in deze controversiële opvatting worden er niet mee geconfronteerd.

[.oisyn]

Ethernal Five schreef op zondag 07 juni 2015 @ 22:26:
[...]


rot13 is ook geen manier om een string kleiner te maken, maar om de string niet direct leesbaar te maken.

Oftewel, encryptie.

[HollowGamer]

.oisyn schreef op maandag 08 juni 2015 @ 10:47:
[...]

Oftewel, encryptie.

In mijn ogen is encryptie iets echt zodanig 'sleutelen' op een zo'n meest veilige/beste manier, dat is bij rot13 dus niet het geval.

Maar in feite valt het inderdaad onder encryptie. Net hetzelfde als je uit een (lange) string alle 5'en vervangt door 1'en.

[.oisyn]

HollowGamer schreef op maandag 08 juni 2015 @ 14:15:
[...]

In mijn ogen is encryptie iets echt zodanig 'sleutelen' op een zo'n meest veilige/beste manier, dat is bij rot13 dus niet het geval.

Dus als er een flaw in een bestaand encryptie-algoritme gevonden wordt, dan is het in jouw boekje dus geen encryptie meer? Encryptie zegt niets over de effectiviteit. ROT13 is gewoon een applicatie van een Caesar cipher.

Maar in feite valt het inderdaad onder encryptie. Net hetzelfde als je uit een (lange) string alle 5'en vervangt door 1'en.

Niet als je alle 1'en niet ook vervangt door 5'en of een ander ongebruikt symbool, want dan valt het onder hashing

[HollowGamer]

.oisyn schreef op maandag 08 juni 2015 @ 14:59:
[...]

Dus als er een flaw in een bestaand encryptie-algoritme gevonden wordt, dan is het in jouw boekje dus geen encryptie meer? Encryptie zegt niets over de effectiviteit. ROT13 is gewoon een applicatie van een Caesar cipher.


[...]

Niet als je alle 1'en niet ook vervangt door 5'en of een ander ongebruikt symbool, want dan valt het onder hashing

In mijn ogen is het dan geen encryptie meer. Het is hetzelfde als een grote muur met een gat erin genoeg om erdoor te kruipen. Het is dan nog wel een muur, maar niet meer als zodanig. Zeker als je te maken hebt met kostbare/privacy gevoelige gegevens.

[Sebazzz]

HollowGamer schreef op maandag 08 juni 2015 @ 17:00:
[...]

In mijn ogen is het dan geen encryptie meer.

Er is weinig aan te vinden het is gewoon encryptie. De sleutel bij een rotatieencryptie zoals rot13 is alleen simpel, zoals in dit geval '13' wat voor het aantal posities rotatie staat.

[emnich]

Natuurlijk is het taaltechnisch nog wel encryptie maar als jij een systeem laat maken en de maker belooft daarin encryptie te gebruiken dan voel je je toch bekocht als dat rot13 blijkt te zijn.

Het sluit niet meer aan bij de verwachting die we hebben van encryptie en in die zin mag je best stellen dat het geen encryptie meer is.

[gekkie]

Ben je even een weekendje weg .. mis je gelijk een indepth discussie over je ROT-13 .. beter gezegd dubbel ROT-13 ... omdat dubbel altijd uhmm dubbel zo sterk is .. toch ?

[Brent]

Sebazzz schreef op maandag 08 juni 2015 @ 17:05:
[...]

Er is weinig aan te vinden het is gewoon encryptie. De sleutel bij een rotatieencryptie zoals rot13 is alleen simpel, zoals in dit geval '13' wat voor het aantal posities rotatie staat.

Leukere vraag is misschien: is morse-code encryptie?

[emnich]

Brent schreef op maandag 08 juni 2015 @ 17:40:
[...]

Leukere vraag is misschien: is morse-code encryptie?

Is Duits dan ook encryptie

[gekkie]

Hangt er een beetje vanaf als je de wikipedia pagina defnitie van cryptografie pakt (de vanDale doet sowieso niet aan crypto):

Cryptografie of geheimschrift (uit het Grieks, κρυπτει kryptei "verborgen," en γράφω gráfo "schrijven") houdt zich bezig met technieken voor het verbergen of zodanig versleutelen van te verzenden informatie, dat het voor een cryptoanalist, een persoon die toegang heeft tot het kanaal tussen zender en ontvanger, en dus als het ware 'mee kan luisteren', onmogelijk is om tegen aanvaardbare inspanning uit de getransporteerde data af te leiden welke informatie er door de zender was verzonden en welke partijen daarbij betrokken waren. Cryptografie wordt gebruikt om gegevens over te dragen die niet leesbaar mogen zijn door andere partijen. Enkel de zender en ontvanger beschikken over de juiste sleutel om de gegevens terug om te zetten in hun originele vorm.

kortom als diegene die toegang heeft tot je bericht in morse code je schoonmoeder* is .. dan heb je een aardige kans .. is het crypto -analist ..

(* briljante schoonmoeders uitgesloten van deelname)

Wat dan weer wel een probleem is met de definitie, is dat "gekraakte" encryptie dan dus geen encryptie meer is .. en de kraak dus eigenlijk ook geen kraak. Hmm interessant .. zou je als advocado in een rechtzaak moeten gebruiken

[ Voor 11% gewijzigd door gekkie op 08-06-2015 17:54 ]

[Brent]

emnich schreef op maandag 08 juni 2015 @ 17:50:
[...]

Is Duits dan ook encryptie

De Amerikanen gebruikten toch Navajo voor de radio in WW2?

Ja dus

[ Voor 3% gewijzigd door Brent op 08-06-2015 17:52 ]

[.oisyn]

HollowGamer schreef op maandag 08 juni 2015 @ 17:00:
[...]

In mijn ogen is het dan geen encryptie meer. Het is hetzelfde als een grote muur met een gat erin genoeg om erdoor te kruipen. Het is dan nog wel een muur, maar niet meer als zodanig.

Wauw. Dus een huis heeft amper muren. Immers, in de meesten zitten wel een gat waar je doorheen kan kruipen (genaamd een kozijn)

Encryptie is encryptie. Effectiviteit is compleet irrelevant binnen de definitie van encryptie.

[HollowGamer]

.oisyn schreef op maandag 08 juni 2015 @ 18:14:
[...]

Wauw. Dus een huis heeft amper muren. Immers, in de meesten zitten wel een gat waar je doorheen kan kruipen (genaamd een kozijn)

Encryptie is encryptie. Effectiviteit is compleet irrelevant binnen de definitie van encryptie.

Dat is dus een 'gat' die je dicht kan maken (same voor een deur). Een zwakke plek binnen encryptie kan niet altijd worden gedicht (om een of meerdere redenen).

Het laatste ben ik overigens wel met je eens (puur de definitie). Bij gebruik zou ik toch meenemen of de encryptie wel echt effectief is, al zou ik meer spreken van of het voldoet.

[Slurpie]

.oisyn schreef op maandag 08 juni 2015 @ 18:14:
[...]

Wauw. Dus een huis heeft amper muren. Immers, in de meesten zitten wel een gat waar je doorheen kan kruipen (genaamd een kozijn)

Encryptie is encryptie. Effectiviteit is compleet irrelevant binnen de definitie van encryptie.

Daarbij ligt het er ook nog aan in hoeverre de encryptie niet te kraken moet zijn. En dat zijn toch vaak economische vraag stukken.

In theorie is alle encryptie te brute forcen op termijn. Iets met slimmigheden en rekenkracht.

[mcDavid]

Watj betreft is het vooral de vraag hoe makkelijk de sleutel te achterhalen valt. Bij Morse of rot13 is het bestuderen van een klein deel van een bericht voldoende om de sleutel te achterhalen waarmee het bericht versleuteld is. Een goeie encryptie is misschien te bruteforcen maar de sleutel is niet terug te halen uit het ontcijferen van het bericht.
Ook als de sleutel publiek domein is, is er wmb geen sprake van encryptie (zoals bijv base64).

Ik ben onlangs nog zijdelings betrokken geweest bij een relletje over een database die publiekelijk toegankelijk was in de vorm van een csv bestand waarvan alle karakters ascii encoded waren (eigenlijk een dubbel ascii encoded document dus).
De publicerende partij meende dat de database misbruikt werd door gebruikers die de encryptie gekraakt hadden. De gebruikers daarentegen waren zich van geen kwaad bewust omdat ze slechts het publiek toegankelijke bestand gedownload en ascii-decoded hadden.

[ Voor 36% gewijzigd door mcDavid op 08-06-2015 19:26 ]

[emnich]

.oisyn schreef op maandag 08 juni 2015 @ 18:14:
[...]

Encryptie is encryptie. Effectiviteit is compleet irrelevant binnen de definitie van encryptie.

Onzin, natuurlijk is effectiviteit relevant. Duits en morse kan je niet met goed fatsoen encryptie noemen.

Als een sleutel zo algemeen bekend is dat iedereen er toegang toe heeft is het geen encryptie meer. In vrijwel elke definitie staat wel iets over effectiviteit.

[Douweegbertje]

emnich schreef op maandag 08 juni 2015 @ 19:33:
[...]

Onzin, natuurlijk is effectiviteit relevant. Duits en morse kan je niet met goed fatsoen encryptie noemen.

Als een sleutel zo algemeen bekend is dat iedereen er toegang toe heeft is het geen encryptie meer. In vrijwel elke definitie staat wel iets over effectiviteit.

Sure, maar stel dat ik wil weten wat er staat in rot13, wat is daar dan de definitie van? Alsnog gewoon decrypten of is het dan opeens 'gewoon lezen'... rot13 is gewoon een encryptiealgoritme. Dan kun je wel verdomd moeilijk gaan lopen doen om er effectiviteit erbij te halen maar dan heb je het over heel iets anders.
Indien ik iets online wil zetten maar bijvoorbeeld een zoekmachine mag niet weten wat er staat, kan ik het met rot13 encrypten. Mijn effectiviteit is dan gewoon 100%. Dus daar gaat je argument al.

Wellicht kun je het obfuscation noemen, maar het feit blijft dat er alsnog een 'key' is, al dan niet standaard meegeleverd (mits je er iets van snapt) maar dan is het alsnog geencrypt.. echter met de key erin.

Dan nog verder.

Als een sleutel zo algemeen bekend is dat iedereen er toegang toe heeft is het geen encryptie meer.

Ja precies. asymetrische crypto is geen encryptie meer. Heel TLS en wat dan ook is geen encryptie want de key is bekend (). Het is precies het doel om een key mee te geven, want anders kan niemand het ook decrypten.

Duits en morse kan je niet met goed fatsoen encryptie noemen

En toch is het zo. Als je geen Duits kunt, dan moet je het toch ontcijferen? Prima encryptie dus. Dat sommige het algoritme weten / 'de key' waardoor het makkelijk lijkt, doet er helemaal niets aan toe.

[ Voor 11% gewijzigd door Douweegbertje op 09-06-2015 00:36 ]

[emnich]

Douweegbertje schreef op dinsdag 09 juni 2015 @ 00:32:
[...]


Sure, maar stel dat ik wil weten wat er staat in rot13, wat is daar dan de definitie van? Alsnog gewoon decrypten of is het dan opeens 'gewoon lezen'... rot13 is gewoon een encryptiealgoritme. Dan kun je wel verdomd moeilijk gaan lopen doen om er effectiviteit erbij te halen maar dan heb je het over heel iets anders.
Indien ik iets online wil zetten maar bijvoorbeeld een zoekmachine mag niet weten wat er staat, kan ik het met rot13 encrypten. Mijn effectiviteit is dan gewoon 100%. Dus daar gaat je argument al.

Mijn argument is dat effectiviteit een rol speelt, als het 100% effectief is dan zou het er dus gewoon onder kunnen vallen.

Echter je hebt voor encryptie een sleutel nodig. Bij rot13 is er geen sleutel, alleen een algoritme. Rot13 is dus géén encryptie maar alleen coderen. Als je het wilt lezen moet je het dus decoderen.

Ja precies. asymetrische crypto is geen encryptie meer. Heel TLS en wat dan ook is geen encryptie want de key is bekend ([afbeelding]). Het is precies het doel om een key mee te geven, want anders kan niemand het ook decrypten.

Maar je geeft alleen de key aan degene die het moet decrypten, zonder deze sleutel is het niet leesbaar.

En toch is het zo. Als je geen Duits kunt, dan moet je het toch ontcijferen? Prima encryptie dus. Dat sommige het algoritme weten / 'de key' waardoor het makkelijk lijkt, doet er helemaal niets aan toe.

De key != algoritme. Bij Morse en Duits ontbreekt de key en is er alleen een algoritme en is het dus geen encryptie.

[Anoniem: 26306]

[b][message=44374908,noline]Ethernal Five schreef op zondag 07 juni 2015

Ook is het helemaal niet verkeerd om md5 te gebruiken voor file hashes zoals jij aangeeft, als je het maar niet voor wachtwoorden gebruikt

Je kunt MD5 op zich wel gebruiken om te bepalen of een file misschien al ergens anders op een share staat en zo dedupliceren. Je kunt MD5 niet gebruiken om de integriteit van een gedownloade ISO te bepalen.

[RayNbow]

emnich schreef op dinsdag 09 juni 2015 @ 07:34:
Echter je hebt voor encryptie een sleutel nodig. Bij rot13 is er geen sleutel, alleen een algoritme. Rot13 is dus géén encryptie maar alleen coderen. Als je het wilt lezen moet je het dus decoderen.

ROT13 is een simpele substitutieversleuteling waarbij de sleutel 13 is.

[emnich]

RayNbow schreef op dinsdag 09 juni 2015 @ 07:46:
[...]

ROT13 is een simpele substitutieversleuteling waarbij de sleutel 13 is.

Er is géén sleutel bij rot13!

[begintmeta]

Hoe ontsleutel je rot13 dan? De sleutel is toch gewoon in beide richtingen x=13 in het algoritme 'rotate by x places'?

[ Voor 59% gewijzigd door begintmeta op 09-06-2015 09:08 . Reden: eerst niet goed geformuleerd ]

[Douweegbertje]

emnich schreef op dinsdag 09 juni 2015 @ 07:54:
[...]

Er is géén sleutel bij rot13!

Stop gewoon.

[emnich]

Douweegbertje schreef op dinsdag 09 juni 2015 @ 08:54:
[...]


Stop gewoon.

Tja, misschien wel beter want tegen zo veel domheid kan ik niet op....

[begintmeta]

emnich schreef op dinsdag 09 juni 2015 @ 09:07:
[...]

Tja, misschien wel beter want tegen zo veel domheid kan ik niet op....

Wat is de definitie van 'sleutel'? Als ik naar de definities op Wikipedia kijk (nl, en, de), ontkom je er volgens mij eigenlijk niet aan dat ROT13 een sleutel heeft, of tenminste kan hebben.

(offtopic natuurlijk)

[kenneth]

emnich schreef op dinsdag 09 juni 2015 @ 09:07:

Tja, misschien wel beter want tegen zo veel domheid kan ik niet op....

RayNbow komt met een argument, jij antwoordt met zoveel als "Nietes!" en dan noem je zijn argument domheid?

quote: https://en.wikipedia.org/wiki/Caesar_cipher

In cryptography, a Caesar cipher [...] is one of the simplest and most widely known encryption techniques.

rot13 == caesar == encryptie.

In b4 nog een keer nietes!

[acemoo]

rot13 is toch gewoon een bijnaam voor een ceasar cipher encryptie met sleutel 13?

[emnich]

begintmeta schreef op dinsdag 09 juni 2015 @ 09:13:
[...]

Wat is de definitie van 'sleutel'? Als ik naar de definities op Wikipedia kijk (nl, en, de), ontkom je er volgens mij eigenlijk niet aan dat ROT13 een sleutel heeft, of tenminste kan hebben.

(offtopic natuurlijk)

We hadden het over str_rot13

PHP:

string str_rot13 ( string $str )

Hoe kan ik daar een sleutel invoeren?

Maar goed als jullie geen verschil (willen) zien tussen encoding en encryptie dan is het en beetje nutteloos.

[jbdeiman]

emnich schreef op dinsdag 09 juni 2015 @ 07:54:
[...]

Er is géén sleutel bij rot13!

ROT 13 is niets anders dan een rotatiealgoritme met sleutel = 13, alleen staat die hierbij vast.

Voor het gemak: Stel dat je een eigen rotatie algoritme bouwt, genaamd ROT, waarbij je zelf de "key" voor de rotatie kan meegeven en dat je deze functie "rot" noemt.
rot(13) is dan een rotatie algoritme, waarbij je sleutel 13 is. Zonder die sleutel (of je die nu brute forced of weet) is de tekst niet leesbaar. Je kan alleen heel gemakkelijk de sleutel achterhalen.

Bij Rot13() is het zo dat de sleutel altijd op 13 staat, maar verder is dat wezenlijk niet anders dan de losse rot() functie waarbij je zelf een key mee kan geven.

emnich schreef op dinsdag 09 juni 2015 @ 09:37:
[...]

We hadden het over str_rot13

PHP:

string str_rot13 ( string $str )

Hoe kan ik daar een sleutel invoeren?

Maar goed als jullie geen verschil (willen) zien tussen encoding en encryptie dan is het en beetje nutteloos.

Waar je hier de mist in gaat is dat jij vind dat je de sleutel moet kunnen meegeven en dat er anders geen sleutel is. Deze sleutel is er wel (13), maar staat vast ingesteld.

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

[acemoo]

emnich schreef op dinsdag 09 juni 2015 @ 09:37:
[...]

We hadden het over str_rot13

PHP:

string str_rot13 ( string $str )

Hoe kan ik daar een sleutel invoeren?

Maar goed als jullie geen verschil (willen) zien tussen encoding en encryptie dan is het en beetje nutteloos.

The purpose of encoding is to transform data so that it can be properly (and safely) consumed by a different type of system, e.g. binary data being sent over email, or viewing special characters on a web page. The goal is not to keep information secret, but rather to ensure that it’s able to be properly consumed.

The purpose of encryption is to transform data in order to keep it secret from others, e.g. sending someone a secret letter that only they should be able to read, or securely sending a password over the Internet. Rather than focusing on usability, the goal is to ensure the data cannot be consumed by anyone other than the intended recipient(s).

Encoding vs encryptie, ligt er maar net aan wat je bedoeling is.
Wil jij rot13 gebruiken om een crawler je tekst niet te kunnen laten lezen is het encryptie, wil je rot13 gebruiken omdat iemand een systeem bedacht heeft dat alleen rot13 kan inlezen dan is het encoding.

Ik mis alleen even je argument dat sleutel betekend of het encoding of encryptie is.

[.oisyn]

emnich schreef op maandag 08 juni 2015 @ 19:33:
[...]

Onzin, natuurlijk is effectiviteit relevant.

Relevant bij de vraag voor welk doel het dient. Niet relevant voor het algoritme.

Als een sleutel zo algemeen bekend is dat iedereen er toegang toe heeft is het geen encryptie meer. In vrijwel elke definitie staat wel iets over effectiviteit.

Quote eens een paar definities dan. Ik kan je alvast vertellen dat die van wikipedia al niet voldoet aan je stelling.

emnich schreef op dinsdag 09 juni 2015 @ 07:54:
[...]


Er is géén sleutel bij rot13!

Wat je nu zegt is: Er is geen sleutel bij algoritme X waarbij de sleutel Y is
Er werd nergens gesteld dat 13 de sleutel van rot13 is, er werd gesteld dat 13 een substitutieversleuteling is met 13 als sleutel. Ik noemde het eerder al: http://en.wikipedia.org/wiki/Caesar_cipher

emnich schreef op dinsdag 09 juni 2015 @ 09:07:
[...]

Tja, misschien wel beter want tegen zo veel domheid kan ik niet op....

Je bedoelt dat jouw intelligentie nog lager dan "dom" is? Pfff

[emnich]

jbdeiman schreef op dinsdag 09 juni 2015 @ 09:38:
[...]
Waar je hier de mist in gaat is dat jij vind dat je de sleutel moet kunnen meegeven en dat er anders geen sleutel is. Deze sleutel is er wel (13), maar staat vast ingesteld.

Nee, de 13 is onderdeel van je algoritme. Je gebruikt bij rot12, of rot14 gewoon een andere code tabel. Net als dat je bij morse ipv .- voor a -. gaat gebruiken. Ben ik werkelijk de enige die van mening is dat base64, morse of Duits géén encryptie is?

Is mijn plain-text brief opgeslagen als word document dan óók encryptie? En is er dan volgens jullie een verschil tussen encoden en encryptie of is dat hetzelfde?

Wat mij betreft leggen deze sites het prima uit:
https://danielmiessler.co...oding_encryption_hashing/
http://www.di-mgt.com.au/encode_encrypt.html

[ReTechNL]

Base64 is wel encryptie, alleen is het een reversable encryptie zonder private key en dus niet veilig. De definitie van encryptie is maskeren van karakters. Wat dus ook gebeurd bij Base64.

[ Voor 9% gewijzigd door ReTechNL op 09-06-2015 09:55 ]

[begintmeta]

emnich schreef op dinsdag 09 juni 2015 @ 09:50:
...en is er dan volgens jullie een verschil tussen encoden en encryptie of is dat hetzelfde?

Wat mij betreft leggen deze sites het prima uit:
...
http://www.di-mgt.com.au/encode_encrypt.html

Hmmm.... 'encryption is an encoding operation'

Dus ik neem aan dat je het zo ziet: encryptie is altijd encoding maar encoding is niet altijd encryptie. Of toch niet? Daar kan ik prima mee leven.

Maar wat dat allemaal direct met ROT13 en aan of afwezigheid van een 'sleutel' te maken heeft weet ik niet. Ik denk wel dat je zou kunnen zeggen dat bijvoorbeeld Duits geen 'sleutel' heeft in de zin zoals gedefinieerd op de Engelse en Duitse wikipedia ('a piece of information (a parameter) that determines the functional output of a cryptographic algorithm or cipher') en ook dat het geen encryptie is, tenzij elke taal encryptie is. rot13 heeft uiteraard wel een sleutel en kan encryptie zijn.

[ Voor 117% gewijzigd door begintmeta op 09-06-2015 10:05 ]

[kenneth]

emnich, hoe zie jij Caesar cipher dan? Is dat dan met 25 van de 26 mogelijke sleutels wél encryptie?

[emnich]

.oisyn schreef op dinsdag 09 juni 2015 @ 09:48:
[...]
Quote eens een paar definities dan. Ik kan je alvast vertellen dat die van wikipedia al niet voldoet aan je stelling.

In cryptography, encryption is the process of encoding messages or information in such a way that only authorized parties can read it.

wiki

Encryption transforms data into another format in such a way that only specific individual(s) can reverse the transformation. It uses a key, which is kept secret, in conjunction with the plaintext and the algorithm, in order to perform the encryption operation. As such, the ciphertext, algorithm, and key are all required to return to the plaintext.

bron

Encryption is the conversion of electronic data into another form, called ciphertext, which cannot be easily understood by anyone except authorized parties.

bron

begintmeta schreef op dinsdag 09 juni 2015 @ 09:54:
[...]


Hmmm.... 'encryption is an encoding operation'

Dus ik neem aan dat je het zo ziet: encryptie is altijd encoding maar encoding is niet altijd encryptie. Of toch niet?

Klopt, net als dat een vlieg een insect is maar een insect is niet altijd een vlieg....

Maar goed, zoals gezegd, als ik hier de enige ben die een verschil ziet tussen encoden en encryptie dan heeft verdere discussie niet zo veel zin.

[begintmeta]

emnich schreef op dinsdag 09 juni 2015 @ 10:07:
...
Maar goed, zoals gezegd, als ik hier de enige ben die een verschil ziet tussen encoden en encryptie dan heeft verdere discussie niet zo veel zin.

Ik zie ook wel een verschil, maar toch zie ik rot13 kennelijk anders dan jij.

[ Voor 60% gewijzigd door begintmeta op 09-06-2015 10:12 ]

[emnich]

begintmeta schreef op dinsdag 09 juni 2015 @ 10:08:
[...]

Ik zie ook wel een verschil, maar toch zie ik rot13 kennelijk anders dan jij.

Wat is dan volgens jou het verschil?

[RayNbow]

emnich schreef op dinsdag 09 juni 2015 @ 09:37:
[...]

We hadden het over str_rot13

PHP:

string str_rot13 ( string $str )

Hoe kan ik daar een sleutel invoeren?

PHP past hier gewoon een hypermoderne techniek toe, genaamd partial application.

Dat kan in een taal als Haskell ook:

Haskell:

import Data.Char

rot k s = map f s
  where 
    f c
     | c >= 'A' && c <= 'Z' = chr $ (ord c - ord 'A' + k) `mod` 26 + ord 'A'
     | c >= 'a' && c <= 'z' = toLower . f . toUpper $ c
     | otherwise = c


rot13 = rot 13

[acemoo]

Ik denk dat emnich van mening is dat een encryptie methode tot encoding methode "degradeerd" na verloop van tijd als te veel mensen hem kunnen decoderen. Onder het motto, dan kan je niet meer bepalen dat alleen de juiste personen het bericht kunnen lezen.
Het gehamer op een sleutel komt dan van dat je een algoritme zonder sleutel sneller zou moeten kunnen herkennen als met een sleutel?

[begintmeta]

emnich schreef op dinsdag 09 juni 2015 @ 10:11:
[...]

Wat is dan volgens jou het verschil?

Vooral de intentie waarmee je encodeert. (zoals ook al aangegeven in br men in "[alg] Slechtste programmeervoorbeelden deel 5")

Ook hier verwijs ik naar je eigen bron:
'In short:

Encryption = encipherment = make secret
Encoding = to convert format, not necessarily securely'

Qua effectiviteit ('make secret'). Tegen mijn dochtertje kan ik rot(13) dat denk ik nog wel als encryptie gebruiken, tegen mij kan je AES(128-bitssleutel) nog wel als encryptie gebruiken, tegen een super-NSA een one-time-pad vermoedelijk wel, maar AES(128-bitssleutel) is misschien voor een dergelijke super-NSA ook encoding, geen encryptie (in 'jouw zin').

Het is allemaal encoding, of het ook encryptie is, wordt simpelweg door de intentie bepaald. Of het effectieve encryptie is, wordt dan weer door de wereld waarin wordt geencodeert bepaald.

[ Voor 18% gewijzigd door begintmeta op 09-06-2015 10:20 ]

[gekkie]

Kortom of iets encryptie is hangt af van de mogelijkheden / capaciteiten van de afluisterende partij.
Het lastige is dat die niet altijd volledig in te schatten zijn door de verzendende en ontvangende partij.
Vanuit het perspectief van de verzendende en ontvangende partij kan er dus nog sprake zijn van encryptie, terwijl dit volgens een universele waarheid (voor zover die bestaat) dan wel waarheid vanuit de afluisterende partij, dit niet meer zo is.

[.oisyn]

emnich schreef op dinsdag 09 juni 2015 @ 10:07:
Maar goed, zoals gezegd, als ik hier de enige ben die een verschil ziet tussen encoden en encryptie dan heeft verdere discussie niet zo veel zin.

Encryptie is een concept, encoding is een toepassing. Encryptie wordt toegepast door middel van encoding. Block ciphers zoals de meeste moderne encryptiemethoden zijn ook gewoon een vorm van encoding. Je encode blokken van N bits in N andere bits (en daarmee zijn het feitelijk ook gewoon substitution ciphers). Zeggen dat iets een encoding is in plaats van encryptie slaat dus nergens op. Je kunt hooguit stellen dat encryptie niet het beoogde doel was van de encoding.

[ Voor 6% gewijzigd door .oisyn op 09-06-2015 10:23 ]

[Dido]

gekkie schreef op dinsdag 09 juni 2015 @ 10:20:
Kortom of iets encryptie is hangt af van de mogelijkheden / capaciteiten van de afluisterende partij.
Het lastige is dat die niet altijd volledig in te schatten zijn door de verzendende en ontvangende partij.
Vanuit het perspectief van de verzendende en ontvangende partij kan er dus nog sprake zijn van encryptie, terwijl dit volgens een universele waarheid (voor zover die bestaat) dan wel waarheid vanuit de afluisterende partij, dit niet meer zo is.

Dat is op zich wel interessant.

Het is in veel wetgevingen verboden om beveiligingen van systemen te omzeilen. In het geval van ge-encrypte data is dat dus het decrypten ervan.

Maar als je stelt dat het per definitie geen encryptie is als jij het kunt kraken, dan is deregelijke wetgeving dus per definitie een dode letter.

emnich schreef op dinsdag 09 juni 2015 @ 09:50:
Nee, de 13 is onderdeel van je algoritme.

En mijn huissleutel is geen sleutel want de unieke kenmerken ervan zitten al in de sleutel

Caesar met sleutel 13 is hetzelfde als rot13. Een slot waar mijn specifieke sleutel op past is "mijn voordeurslot".

Omdat je aan de combinatie van algoritme plus sleutel een eigen naampje geeft is er opeens geen sleutel meer dus? Ik vind het niet zo gek dat je weinig mensen mee krijgt

Je gebruikt bij rot12, of rot14 gewoon een andere code tabel.

Ik gebruik rot(key)

Ben ik werkelijk de enige die van mening is dat base64, morse of Duits géén encryptie is?

Oh, ik ben met je eens dat Duits geen encryptie is volgens gangbare definities. Het is ook geen encoding.

De meest voor de hand liggende reden daarvoor is dat er geen enkel algoritme is dat voor een gegeven input een vaste ouput garandeert. Met andere woorden, een gelijke input kan tot verschillende valide versies van de output leiden.

Mijn Duits is niet zo goed, maar tussen Engels en Nederlands kan ik eenzelfde Engels woord als "dijk" en als "pot" "encoden". En nl("pot") kan weer en("pot") of en("weed") worden. Dat is dus geen werkbare encoding.

Voor morse en base64 geldt dat wel, vandaar dat ze ook worden gebruikt als encoding. En als ik die gebruik om mijn data voor iemand moeilijk of onmogelijk leesbaar te maken, is het voor mij encryptie.

Dat iedere IT-nerd bij base64 onmiddelijk weet hoe hij de text moet ontcijferen betekent dat het _slechte_ encryptie is, zeker als ik mijn data voor IT'ers wil verstoppen.

Maar als slechte encryptie geen encryptie is, is dan alle encryptie per definitie goed?

Is mijn plain-text brief opgeslagen als word document dan óók encryptie?

Als je je word document als raw binary uitprint dan zal het voor veel mensen effectief geencrypt zijn, hoor.

Mooi voorbeeldje (mogelijk apcryph) over ASCii encoding als effectieve encryptie is het verhaal over een bepaald encryptiealgoritme (welk een toeval) dat niet uitgevoerd mocht worden uit de VS. Om controles op electronische dragers te omzeilen is de broncode uitgeprint en meegenoemen. Geen haan die ernaar kraaide.
Op dat moment is het printen in leesbare text dus een effectieve vorm van encryptie gebeleken!

[gekkie]

Dido schreef op dinsdag 09 juni 2015 @ 13:28:
[...]
Dat is op zich wel interessant.

Het is in veel wetgevingen verboden om beveiligingen van systemen te omzeilen. In het geval van ge-encrypte data is dat dus het decrypten ervan.

Maar als je stelt dat het per definitie geen encryptie is als jij het kunt kraken, dan is deregelijke wetgeving dus per definitie een dode letter.

Vandaar mijn conclusie een stukje daar boven dat de wikipedia definitie opzich leuk advocatenvoer zou kunnen zijn. Al gok ik dat de wetgever het allemaal algemener heeft gehouden, waardoor het als nog wel verboden zal zijn omdat het voldoende evident wordt geacht dat de verzender en ontvanger in iedergeval het doel hadden om niet afgeluisterd te worden. Of het ook afdoende is om niet aansprakelijk te zijn jegens derden die communiceren via een door jou als encrypt zijnde aangeboden communicatiekanaal is dan weer een ander punt.

[Brent]

Dido schreef op dinsdag 09 juni 2015 @ 13:28:
[...]
Oh, ik ben met je eens dat Duits geen encryptie is volgens gangbare definities. Het is ook geen encoding.

Als geheimschriften als encryptie gerekend worden (Het konijn heeft het hol verlaten!), dan een andere taal toch zeker ook (Navajo ten tijde van WW2). Het doel, obfuscatie, wordt bij beide bereikt, tot de sleutel ontdekt wordt.

Misschien is het betere antwoord dat er geen zuiver verschil is. Tekens zoals het Latijns alfabet zijn natuurlijk al codering op zich, en een mensentaal is misschien ook een manier van het coderen van gedachten. Encryptie hangt volgens die wikipedia definitie van de ontvanger af (wat zijn zijn capaciteiten), en dat is Navajo door de radio spreken evengoed encryptie als een Engima machine.

Misschien is het zinvol mathematische encryptie van overige encryptie te onderscheiden?

[emnich]

Dido schreef op dinsdag 09 juni 2015 @ 13:28:
De meest voor de hand liggende reden daarvoor is dat er geen enkel algoritme is dat voor een gegeven input een vaste ouput garandeert. Met andere woorden, een gelijke input kan tot verschillende valide versies van de output leiden.

Als ik in Google translate een tekst invoer, komt daar toch echt telkens dezelfde output uit (totdat hun algortime geupdate is). Is het dan wel ecnryptie?

Voor morse en base64 geldt dat wel, vandaar dat ze ook worden gebruikt als encoding. En als ik die gebruik om mijn data voor iemand moeilijk of onmogelijk leesbaar te maken, is het voor mij encryptie.

[...]
Dat iedere IT-nerd bij base64 onmiddelijk weet hoe hij de text moet ontcijferen betekent dat het _slechte_ encryptie is, zeker als ik mijn data voor IT'ers wil verstoppen.

Maar als slechte encryptie geen encryptie is, is dan alle encryptie per definitie goed?

[...]

Als je je word document als raw binary uitprint dan zal het voor veel mensen effectief geencrypt zijn, hoor.

Volgens mij moet het bij encryptie gaan over wie jij wilt dat het kan lezen en niet wie jij niet wil dat het kan lezen. Subtiel verschil.

Mooi voorbeeldje (mogelijk apcryph) over ASCii encoding als effectieve encryptie is het verhaal over een bepaald encryptiealgoritme (welk een toeval) dat niet uitgevoerd mocht worden uit de VS. Om controles op electronische dragers te omzeilen is de broncode uitgeprint en meegenoemen. Geen haan die ernaar kraaide.
Op dat moment is het printen in leesbare text dus een effectieve vorm van encryptie gebeleken!

Op die manier kan je dus ook een kilo cocaïne encrypten door het onder je reserve wiel te plaatsen . Iets verstoppen of op een andere manier langs een controle krijgen != encryptie.

[Dido]

emnich schreef op dinsdag 09 juni 2015 @ 13:53:
Als ik in Google translate een tekst invoer, komt daar toch echt telkens dezelfde output uit (totdat hun algortime geupdate is). Is het dan wel ecnryptie?

Ja. Als jij niet weet dat ik 1) google translate heb gebruikt, 2) niet weet welke doeltaal ik daarin heb gekozen en 3) geen talenwonder bent, dan mag ik er vanuit gaan dat "miezaka mamaky ity" of "sim nyeem qhov no" of "bu o'qish uchun harakat" of "ab pravi tas kirah" redelijk (niet goed!) encrypted zijn.

Volgens mij moet het bij encryptie gaan over wie jij wilt dat het kan lezen en niet wie jij niet wil dat het kan lezen. Subtiel verschil.

Dat is een interessant punt. crypho betekent verbergen, niet vertellen. Het gaat bij encryptie dus wel om verbergen, en verbergen doe je voor degenen die het bniet mogen zien.
Het is wel de uitdaging om de data niet te vernitigen en toegankelijk te houden voor degenen voor wie ik het niet verberg, natuurlijk. Anders zijn er genoeg triviale oplossingen.

Op die manier kan je dus ook een kilo cocaïne encrypten door het onder je reserve wiel te plaatsen . Iets verstoppen of op een andere manier langs een controle krijgen != encryptie.

Als jij die coke weet te veranderen in reservewielen, ja.

Punt was dat het ging om een stuk electronische programmacode, die in uitgeprinte toestand niet herkend werd als computercode, en door die encodering dus verstopt werdt. En verstopppen van data door encodering is wat mij betreft encryptie.

jouw idee dat slechte ecryptie geen encryptie is komt op me over alsof jij ook kleine kinderen pest als ze zich niet goed verstoppen. Die zijn helemaal geen verstoppertje aan het spelen, want als ze dat deden werden ze niet gevonden.

En dan doorgaan dat ze het geen verstoppertje mogen noemen, natuurlijk.

[emnich]

Dido schreef op dinsdag 09 juni 2015 @ 14:25:
[...]

Ja. Als jij niet weet dat ik 1) google translate heb gebruikt, 2) niet weet welke doeltaal ik daarin heb gekozen en 3) geen talenwonder bent, dan mag ik er vanuit gaan dat "miezaka mamaky ity" of "sim nyeem qhov no" of "bu o'qish uchun harakat" of "ab pravi tas kirah" redelijk (niet goed!) encrypted zijn.

Tja als jij beloofd dat je geen rot13 gebruikt dan is gel ernqvat guvf ook prima encrypted.

Punt was dat het ging om een stuk electronische programmacode, die in uitgeprinte toestand niet herkend werd als computercode, en door die encodering dus verstopt werdt. En verstopppen van data door encodering is wat mij betreft encryptie.

jouw idee dat slechte ecryptie geen encryptie is komt op me over alsof jij ook kleine kinderen pest als ze zich niet goed verstoppen. Die zijn helemaal geen verstoppertje aan het spelen, want als ze dat deden werden ze niet gevonden.

En dan doorgaan dat ze het geen verstoppertje mogen noemen, natuurlijk.

Ja, op die manier is vrijwel alles encryptie. Als ik even wacht tot mijn kind uit de kamer is voordat ik iets aan mijn vrouw vertel, is het bij jou ook encryptie. Of ik fluister iemand iets in het oor. Of ik geef stiekem een briefje aan iemand zonder dat een 3e het ziet.

Encryptie moet (m.i.) gaan over of een ontvanger anders dan degene voor wie het bestemd is, het bericht eenvoudig kan lezen. Als jij alles wat je voor één specifieke ontvanger verbogen kan houden als encryptie ziet dan is de discussie zinloos want dan hebben we een totaal ander beeld van wat encryptie is.

[MBV]

emnich schreef op dinsdag 09 juni 2015 @ 14:44:
[...]


Encryptie moet (m.i.) gaan over of een ontvanger anders dan degene voor wie het bestemd is, het bericht eenvoudig kan lezen. Als jij alles wat je voor één specifieke ontvanger verbogen kan houden als encryptie ziet dan is de discussie zinloos want dan hebben we een totaal ander beeld van wat encryptie is.

En daar begon de hele discussie toch mee? Iemand beweerde dat Rot13 encryptie was, iemand anders beweerde dat alles wat kraakbaar is geen encryptie is (en bij mijn weten bestaat er volgens die definitie geen encryptie meer, dankzij quantum-computers).

De waarheid ligt ergens in het midden. Wat iemand al aangaf: als je een word-document als ASCII uitprint is dat tegenover iemand zonder hulpmiddelen een goede encryptie: om dat zonder computer te ontcijferen ben je heel lang bezig. En ook iemand met computer: je moet behoorlijk veel van bestandsformaten weten om te zien dat het een word-document is.

[begintmeta]

Ik blijf erbij dat de intentie het beste criterium is (Het is allemaal encoding, of het ook encryptie is, wordt simpelweg door de intentie bepaald. Of het effectieve encryptie is, wordt dan weer door de wereld waarin wordt geencodeert bepaald.)

MBV schreef op dinsdag 09 juni 2015 @ 14:52:
... en bij mijn weten bestaat er volgens die definitie geen encryptie meer, dankzij quantum-computers...

Wat doen quantumcomputers met OTP?

[ Voor 33% gewijzigd door begintmeta op 09-06-2015 15:05 ]

[emnich]

Maar daarbij ga je ervan uit dat je weet wie het onderschept. Het verschil zit er in of je voor een specifiek iemand iets moet verbergen en de rest van de wereld mag het weten of dat en specifiek iemand het mag weten en onbekenden niet.

[.oisyn]

MBV schreef op dinsdag 09 juni 2015 @ 14:52:
(en bij mijn weten bestaat er volgens die definitie geen encryptie meer, dankzij quantum-computers).

Niet alle huidige encryptiealgoritmen zijn kraakbaar met een kwantumalgoritme, en tot slot is er nog kwantumencryptie

[ Voor 16% gewijzigd door .oisyn op 09-06-2015 15:42 ]

[RayNbow]

emnich schreef op dinsdag 09 juni 2015 @ 14:44:
[...]

Tja als jij beloofd dat je geen rot13 gebruikt dan is gel ernqvat guvf ook prima encrypted.

Heb je hier toevallig een Caesar cipher gebruikt met als sleutel 39?

[kenneth]

emnich schreef op dinsdag 09 juni 2015 @ 15:04:
Maar daarbij ga je ervan uit dat je weet wie het onderschept. Het verschil zit er in of je voor een specifiek iemand iets moet verbergen en de rest van de wereld mag het weten of dat en specifiek iemand het mag weten en onbekenden niet.

En als ik iets sign met een private key, is het dan nog encryptie? De hele wereld kan namelijk mijn public key van keybase.io plukken.

[begintmeta]

kenneth schreef op dinsdag 09 juni 2015 @ 15:16:
...
En als ik iets sign met een private key, is het dan nog encryptie?...

?

[kenneth]

begintmeta schreef op dinsdag 09 juni 2015 @ 15:23:
[...]

?

De tekst is dan niet verborgen maar je gebruikt wel cryptografie voor de signature. Heet het dan nog encryptie of niet?

[MBV]

emnich schreef op dinsdag 09 juni 2015 @ 15:04:
Maar daarbij ga je ervan uit dat je weet wie het onderschept. Het verschil zit er in of je voor een specifiek iemand iets moet verbergen en de rest van de wereld mag het weten of dat en specifiek iemand het mag weten en onbekenden niet.

Doel rechtvaardigt de middelen:
- als ik wil dat niet iedere jan-lul op het vliegveld mijn tekst in 5 seconden kan lezen, is ROT13 genoeg
- als ik wil dat 90% van de mensen het niet kan lezen, en die 10% er een half uur voor nodig heeft, is een word-document als ASCII genoeg
- als ik bij de AIVD werk en zeker wil weten dat wat Nederland naar Afghanistan verstuurt niet te lezen is door IS binnen 10 jaar, zijn de huidige 'echte' encryptiealgoritmen goed genoeg
- als ik bij de AIVD werk en iets 'voor eeuwig' onleesbaar wil houden, maar wel wil kunnen aantonen dat iets nu bekend is, dan moet ik met quantum-encryptie werken

IMHO is er geen enkele reden waarom ROT13 geen encryptie is, of het voor je doel nuttig is is een tweede vraag.

Zullen we het weer over programmeren hebben?

[farlane]

Is programmeren/het schrijven van programmacode encryptie?

[ Voor 40% gewijzigd door farlane op 09-06-2015 16:39 ]

[Anoniem: 391619]

Als je cryptische nietszeggende vars gebruikt wel

[HollowGamer]

MBV schreef op dinsdag 09 juni 2015 @ 16:20:
[...]

Doel rechtvaardigt de middelen:
- als ik wil dat niet iedere jan-lul op het vliegveld mijn tekst in 5 seconden kan lezen, is ROT13 genoeg
- als ik wil dat 90% van de mensen het niet kan lezen, en die 10% er een half uur voor nodig heeft, is een word-document als ASCII genoeg
- als ik bij de AIVD werk en zeker wil weten dat wat Nederland naar Afghanistan verstuurt niet te lezen is door IS binnen 10 jaar, zijn de huidige 'echte' encryptiealgoritmen goed genoeg
- als ik bij de AIVD werk en iets 'voor eeuwig' onleesbaar wil houden, maar wel wil kunnen aantonen dat iets nu bekend is, dan moet ik met quantum-encryptie werken

IMHO is er geen enkele reden waarom ROT13 geen encryptie is, of het voor je doel nuttig is is een tweede vraag.

Zullen we het weer over programmeren hebben?

Mee eens.

Excuses voor het starten van de discussie (zo ongeveer), had niet verwacht dat er (toch wel veel) reactie op zou komen.

Voor mij blijft encryptie niet meer encryptie als deze te kraken is of niet werkt met een 'echte' sleutel.
Maar ik begrijp dat het dan nog steeds encryptie is, maar simpelweg een met gaten erin.

De hele rot13 discussie gaat erom of je het mag definiëren als encryptie of als encoden, tenminste dat lees ik zo terug.
Mijn vraag is inmiddels hierin beantwoord omdat ik nu (ongeveer) snap hoe rot13 zijn werk doet.

Maar laten we ook elkaars mening/idee hierin accepteren, het is niet nodig iemand bijvoorbeeld uit te maken voor ..

Back on topic dan maar!

[roy-t]

emnich schreef op dinsdag 09 juni 2015 @ 09:50:
[...]


Nee, de 13 is onderdeel van je algoritme. Je gebruikt bij rot12, of rot14 gewoon een andere code tabel. Net als dat je bij morse ipv .- voor a -. gaat gebruiken. Ben ik werkelijk de enige die van mening is dat base64, morse of Duits géén encryptie is?

Is mijn plain-text brief opgeslagen als word document dan óók encryptie? En is er dan volgens jullie een verschil tussen encoden en encryptie of is dat hetzelfde?

Wat mij betreft leggen deze sites het prima uit:
https://danielmiessler.co...oding_encryption_hashing/
http://www.di-mgt.com.au/encode_encrypt.html

Als je er zo over na denkt is elke vorm van encryptie geen encryptie. Zoals jij er over nadenkt is de key dan altijd onderdeel van je algoritme:

Zo gebruik ik meestal AES_M1JN4W3S0MEWW();

Je Morse voorbeeld loopt ook een beetje spaak. Immers is encryptie altijd de subsitutie van (een reeks van) karakters door andere karakters. Bij encryptie (en encoding) gaat het om de afspraak over hoe je de subsitutie doet (aan de hand van een key).

[.oisyn]

HollowGamer schreef op dinsdag 09 juni 2015 @ 23:23:
De hele rot13 discussie gaat erom of je het mag definiëren als encryptie of als encoden, tenminste dat lees ik zo terug.

Maar die vraag slaat nergens op. Encryptie pas je toe door middel van encoding. Encoding betekent niets meer dan het omzetten in code. Rot13 is dan een codevorm waarbij een A staat voor M, een B voor N, etc. Moderne encryptie-algroritmen zijn dan over het algemeen block ciphers waarbij een blok van N bits wordt getransformeerd naar N andere bits waarbij iedere unieke combinatie van bits als een unieke combinatie van andere bits wordt opgeschreven. Hoe je dat verder bewerkstelligt (met een look up table of een bepaalde mathematisch proces of whatever) doet er verder niet toe.

[emnich]

roy-t schreef op woensdag 10 juni 2015 @ 10:57:
[...]


Als je er zo over na denkt is elke vorm van encryptie geen encryptie. Zoals jij er over nadenkt is de key dan altijd onderdeel van je algoritme:

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

Maar die vraag slaat nergens op.

Dus zeggen jullie encryptie===encoding en encoding===encryptie?

[.oisyn]

Als je dat uit mijn voorgaande post haalt stel ik voor om nog eens wat aandachtiger te lezen.

[RayNbow]

roy-t schreef op woensdag 10 juni 2015 @ 10:57:
Immers is encryptie altijd de subsitutie van (een reeks van) karakters door andere karakters.

Niet alleen substitutie. Je hebt ook nog transpositie.

[roy-t]

RayNbow schreef op woensdag 10 juni 2015 @ 11:19:
[...]

Niet alleen substitutie. Je hebt ook nog transpositie.

Dan substitueer je karakters met karakters van een andere plek?

[.oisyn]

RayNbow schreef op woensdag 10 juni 2015 @ 11:19:
[...]

Niet alleen substitutie. Je hebt ook nog transpositie.

Ah good one. De vraag die volgt is dan: is het nog steeds encoding als je gebruik maakt van transpositie . Mijn inziens wel, encoding is niets meer dan "het omzetten in code vorm". Dat je daarbij volgorde aanpast (bijvoorbeeld bij het encoden van een expression string naar RPN) is niet zo relevant.

---

Maar goed, to humor enmich, ik stel:

Encoding is het omzetten van een bericht in code vorm.
Encryptie is het toepassen van cryptographie op een bericht (op wat voor manier dan ook)

Encryptie impliceert doorgaans dat je de handeling van encoding nodig hebt om je doel te bewerkstelligen. Of encoding ook encryptie is hangt af van het beoogde doel. Als je bepaalde symbolen niet kan gebruiken omdat die op een speciale manier geïnterpreteerd worden door de ontvangende partij (zoals control characters in een regex), en je hebt een systeem om die symbolen verbatim te kunnen gebruiken (escapen in het geval van een regex), dan is dat geen vorm van encryptie. Als iemand een algoritme verzint dat ervoor zorgt dat een bericht wordt versleuteld zodat een derde partij het niet (makkelijk) kan lezen, dan is dat een cryptographisch algoritme en is het gebruik ervan encryptie. Rot13 (en Caesar ciphers in het generiek) is daarmee dus encryptie, ookal voldoet die niet meer aan hedendaagse standaarden.

[ Voor 4% gewijzigd door .oisyn op 10-06-2015 12:40 ]

[Brent]

Encoding betekent op zijn minst schrift omzetten in bits, dus encoding is volgens die definitie dus ook encryptie.

[.oisyn]

Brent schreef op woensdag 10 juni 2015 @ 12:50:
Encoding betekent op zijn minst schrift omzetten in bits

Pertinent onwaar. Ik kan op een stuk papier tekst encoden in een set symbolen die ik zojuist heb verzonnen. Daar komt geen bit aan te pas.

dus encoding is volgens die definitie dus ook encryptie.

Hoezo "dus" Ik zeg zojuist dat niet alle vormen van encoden ook encryptie zijn, maar dat er cryptographie bij komt kijken. Waarom is het omzetten naar bits dan ineens wel encryptie?

[emnich]

.oisyn schreef op woensdag 10 juni 2015 @ 12:37:
[...]


Maar goed, to humor enmich, ik stel:

Encoding is het omzetten van een bericht in code vorm.
Encryptie is het toepassen van cryptographie op een bericht (op wat voor manier dan ook)

Encryptie impliceert doorgaans dat je de handeling van encoding nodig hebt om je doel te bewerkstelligen. Of encoding ook encryptie is hangt af van het beoogde doel. Als je bepaalde symbolen niet kan gebruiken omdat die op een speciale manier geïnterpreteerd worden door de ontvangende partij (zoals control characters in een regex), en je hebt een systeem om die symbolen verbatim te kunnen gebruiken (escapen in het geval van een regex), dan is dat geen vorm van encryptie. Als iemand een algoritme verzint dat ervoor zorgt dat een bericht wordt versleuteld zodat een derde partij het niet (makkelijk) kan lezen, dan is dat een cryptographisch algoritme en is het gebruik ervan encryptie. Rot13 (en Caesar ciphers in het generiek) is daarmee dus encryptie, ookal voldoet die niet meer aan hedendaagse standaarden.

Volgens mij zijn we het vrijwel eens alleen verschillen we van mening over wat het doel is en wat `makkelijk` is.

Voor mij moet het doel zijn dat een willekeurige derde je boodschap niet makkelijk kan lezen en alleen degene(n) die je specifiek aanwijst het bericht wél kan lezen. Dat is dus anders dan er voor zorgen dat een specifiek iemand het niet kan lezen (de douane, je dochter, etc).

Daarnaast speelt voor mij de term `makkelijk` een belangrijk rol. Dat betekent inderdaad dat iets wat we vroeger encryptie noemden, nu geen encryptie meer zouden mogen noemen. Net als wat vroeger een zuinige auto was, dat nu niet meer is. Het wordt dan meer obfuscation (bij gebrek aan een beter woord).

Maar goed als het doel anders omschreven wordt en/of de lat voor `makkelijk` ligt net boven `niet in plain sight` dan komen we op een andere definitie uit.

Maar goed, back to slechte programeervoorbeelden

[RayNbow]

emnich schreef op woensdag 10 juni 2015 @ 13:38:
Maar goed, back to slechte programeervoorbeelden

Hoezo? We zitten niet in het [alg] Slechtste programmeervoorbeelden deel 5-topic...

[Brent]

.oisyn schreef op woensdag 10 juni 2015 @ 12:55:
[...]

Pertinent onwaar.

Goed, dan begreep ik je verkeerd.

Wat ik bedoel is dat een bericht per definitie gecodeerd is. Er is geen transmissie van informatie zonder medium.

Coderen is vrij fundamenteel een middel om de obfusceren, en dat is de gangbare definitie van encryptie. Een mate van kwaliteit van obfuscatie is de hoeveelheid werk die er verricht moet worden om het bericht toch te lezen.

Geheimtalen zijn obfuscatie, andere talen kunnen obfuscatie zijn, andere schriften, etc etc.

Informatie is misschien zelfs per definitie gecodeerd?

Ik merkte het eerder hier al op, helaas ging niemand erop in, maar volgens mij zijn de meesten hier onbewust van mening dat het verschil tussen encryptie en andere vormen van codering/obfuscatie een mathematische component is. Daar kan ik prima in meekomen.

[Douweegbertje]

emnich schreef op woensdag 10 juni 2015 @ 13:38:
[...]

Volgens mij zijn we het vrijwel eens alleen verschillen we van mening over wat het doel is en wat `makkelijk` is.

Voor mij moet het doel zijn dat een willekeurige derde je boodschap niet makkelijk kan lezen en alleen degene(n) die je specifiek aanwijst het bericht wél kan lezen. Dat is dus anders dan er voor zorgen dat een specifiek iemand het niet kan lezen (de douane, je dochter, etc).

Daarnaast speelt voor mij de term `makkelijk` een belangrijk rol. Dat betekent inderdaad dat iets wat we vroeger encryptie noemden, nu geen encryptie meer zouden mogen noemen. Net als wat vroeger een zuinige auto was, dat nu niet meer is. Het wordt dan meer obfuscation (bij gebrek aan een beter woord).

Maar goed als het doel anders omschreven wordt en/of de lat voor `makkelijk` ligt net boven `niet in plain sight` dan komen we op een andere definitie uit.

Maar goed, back to slechte programeervoorbeelden

Maar je doet dan net of het een eigenschap is van 'iets'. Een soort kenmerk. Het is groen, en nu issie rood. Wellicht werkt dat op een term als 'snelle computer' die dan nu traag is anno 2015, maar in feite wil je nu zeggen dat een computer.. geen computer meer is, of dus encryptie geen encryptie meer is 'omdat reden x'.
Wellicht dat het nu zwak is, of gewoon slecht (dingen die dus kunnen veranderen ook) maar het blijft encryptie in essentie.

[.oisyn]

Brent schreef op woensdag 10 juni 2015 @ 14:33:
[...]

Goed, dan begreep ik je verkeerd.

Wat ik bedoel is dat een bericht per definitie gecodeerd is.

Mja, ik zou een stuk tekst op papier niet per se als gecodeerd beschouwen, maar je kan het punt maken dat de opgeschreven letters de codes zijn. Dan rest de vraag wat een bericht dan is - de abstracte tekst, of de opgeschreven letters die er staan. Maar dat is een in deze context redelijk nutteloze filosofische discussie, en het maakt voor je argument verder ook niet uit

Coderen is vrij fundamenteel een middel om de obfusceren, en dat is de gangbare definitie van encryptie.

Let wel, je stelling impliceert niet dat coderen altijd obfuscatie betreft (analoog aan: een hond is een dier maar een dier is niet per se een hond)

Een mate van kwaliteit van obfuscatie is de hoeveelheid werk die er verricht moet worden om het bericht toch te lezen.

Geheimtalen zijn obfuscatie, andere talen kunnen obfuscatie zijn, andere schriften, etc etc.

Informatie is misschien zelfs per definitie gecodeerd?

Wat is je punt? Als je hiermee je punt kracht mee wilde zetten dat encoding altijd encryptie is ben ik het er dus niet mee eens (zie bovenstaande hond-dier opmerking)

[.oisyn]

emnich schreef op woensdag 10 juni 2015 @ 13:38:
Dat betekent inderdaad dat iets wat we vroeger encryptie noemden, nu geen encryptie meer zouden mogen noemen. Net als wat vroeger een zuinige auto was, dat nu niet meer is.

Tja, ik blijf erbij: als iemand een algoritme ontwerpt voor encryptie, dan is dat een encryptie-algoritme, en noemen we toepassen van dat algoritme op informatie "encrypten". Of dat algoritme dan vanaf dag 1 ontzettend flawed was of voorbij is gestreefd door de tijd en moderne ontwikkelingen doet daar verder niets aan af.

[Voutloos]

Een Ford Model T is inmiddels een vrij beroerde keuze als je lekker snel, comfortabel en zonder panne naar Benidorm wil rijden met je vakantie. En zonder modificaties is het wellicht onmogelijk om ooit te slagen voor de APK. Maar het is nog steeds een auto.

#verplichteautometafoorbijslependediscussies

[incaz]

emnich schreef op woensdag 10 juni 2015 @ 13:38:
Voor mij moet het doel zijn dat een willekeurige derde je boodschap niet makkelijk kan lezen en alleen degene(n) die je specifiek aanwijst het bericht wél kan lezen. Dat is dus anders dan er voor zorgen dat een specifiek iemand het niet kan lezen (de douane, je dochter, etc).

Dat is in elk geval geen juiste definitie, want encryptie-algoritmen maken gebruik van sleutels, niet van autorisatie. Dus je wijst niet 'iemand' aan die het bericht kan lezen, je gebruikt een sleutel waarvan je meent dat die slechts in handen is van de partij die je beoogt.

[emnich]

.oisyn schreef op woensdag 10 juni 2015 @ 15:12:
Tja, ik blijf erbij: als iemand een algoritme ontwerpt voor encryptie, dan is dat een encryptie-algoritme, en noemen we toepassen van dat algoritme op informatie "encrypten".

Maar dan komen we nog steeds niet tot een definitie van encryptie behalve dan het toepassen van een encryptie-algoritme. In je vorige reactie schreef je nog dat het niet (makkelijk) leesbaar moest zijn. Ligt die lat dan inderdaad op alles wat niet in plain sight is? Ook bij de definitie van cryptografie staat altijd wel iets over aanvaardbare inspanning.

Of is die aanvaardbare inspanning zo boterzacht dat de een rot13 wél encryptie mag noemen en de andere niet en ze beide gelijk hebben?

Volgens mij is het namelijk dat `makkelijk` en aanvaardbare inspanning waar we van mening over verschillen.

incaz schreef op woensdag 10 juni 2015 @ 15:43:
[...]


Dat is in elk geval geen juiste definitie, want encryptie-algoritmen maken gebruik van sleutels, niet van autorisatie. Dus je wijst niet 'iemand' aan die het bericht kan lezen, je gebruikt een sleutel waarvan je meent dat die slechts in handen is van de partij die je beoogt.

Dat wordt een woordenspelletje. Natuurlijk heeft niemand een tovervinger waarmee hij kan wijzen naar iemand die het bericht dan automagisch kan lezen...

Het verschil wat ik probeerde aan te geven is of jij bepaald wie het wel mag lezen (en automatisch iedere andere niet). Of dat jij bepaald wie het niet mag lezen maar mogelijk alle andere wel.

Dus geef jij een sleutel van je huis of zet je een bouncer neer en blokkeert alleen specifieke personen.

[ Voor 32% gewijzigd door emnich op 10-06-2015 15:49 ]

[Brent]

.oisyn schreef op woensdag 10 juni 2015 @ 15:08:

Wat is je punt? Als je hiermee je punt kracht mee wilde zetten dat encoding altijd encryptie is ben ik het er dus niet mee eens (zie bovenstaande hond-dier opmerking)

Mijn punt is het deel dat je niet quotte Dat de discussie altijd 'filosofisch' zal blijven, tenzij we encryptie opbreken in mathematische en overige encryptie. (althans, dit zou ik een goede splitsing vinden)

Want iedereen heeft het hier in feite over dat onderscheid, zonder het te benoemen, en dientengevolge verwarring over woorden aka filosofie

[incaz]

emnich schreef op woensdag 10 juni 2015 @ 15:44:
[...]
Dat wordt een woordenspelletje. Natuurlijk heeft niemand een tovervinger waarmee hij kan wijzen naar iemand die het bericht dan automagisch kan lezen...

In tegendeel... het verschil tussen autorisatie en encryptie lijkt me wezenlijk, zelfs al hebben ze vaak veel met elkaar te maken.

Het verschil wat ik probeerde aan te geven is of jij bepaald wie het wel mag lezen (en automatisch iedere andere niet). Of dat jij bepaald wie het niet mag lezen maar mogelijk alle andere wel.

Dus geef jij een sleutel van je huis of zet je een bouncer neer en blokkeert alleen specifieke personen.

En het punt is dat encryptie altijd het eerste is: een slot met een sleutel. En dan kun je een lullig action-slotje hebben of een zeer precies cilinderslot, maar het blijft een slot met een sleutel, en iedereen die de sleutel heeft kan erin. Totaal anders dan een bouncer dus.

Het moge duidelijk zijn dat rot13 nog iets lager scoort dan het slotje dat op dagboekjes zit zodat iedereen met een paperclipje er alsnog in kan, en dat een behoorlijk encryptiealgoritme beslist complexer is dan een cilinderslot, maar ... het mechanisme blijft een slot met een sleutel, en geen bouncer die op identiteit checkt.

[Vaan Banaan]

Met de naam rot13 geef je al aan wat de sleutel is.
Het is dus niet, zoals met bijvoorbeeld AES of RSA, dat je een sleutel zelf kunt aanmaken.
Daarom hoort rot13 voor mijn gevoel bij en/decoding a la base64.

edit:
Wat een pokke onderwerp

Nee, ik moet het toch meer zien als base64 met een verschoven index table, want je weet, als je het bericht ziet niet of het rot1, rot2, ..., rotXX is.
Dan is rot13 toch encryptie, omdat je moet "bruteforcen" om de plaintext te kunnen achterhalen.
[EDIT2] Kenneth hieronder: ja, dat is precies waar ik mee worstelde. Ok ik stem voor encryptie. Waar is de Poll?

[ Voor 51% gewijzigd door Vaan Banaan op 10-06-2015 16:54 ]

[kenneth]

rot13 is encoding, caesar met sleutel 13 is encryptie

[Douweegbertje]

.oisyn heeft een encryptie badge dus ik zie hier de winnaar van de discussie al.

[emnich]

incaz schreef op woensdag 10 juni 2015 @ 16:07:
[...]


In tegendeel... het verschil tussen autorisatie en encryptie lijkt me wezenlijk, zelfs al hebben ze vaak veel met elkaar te maken.


En het punt is dat encryptie altijd het eerste is: een slot met een sleutel. En dan kun je een lullig action-slotje hebben of een zeer precies cilinderslot, maar het blijft een slot met een sleutel, en iedereen die de sleutel heeft kan erin. Totaal anders dan een bouncer dus.

Het moge duidelijk zijn dat rot13 nog iets lager scoort dan het slotje dat op dagboekjes zit zodat iedereen met een paperclipje er alsnog in kan, en dat een behoorlijk encryptiealgoritme beslist complexer is dan een cilinderslot, maar ... het mechanisme blijft een slot met een sleutel, en geen bouncer die op identiteit checkt.

Het punt is dat hier door sommigen ook Duits als encryptie gezien wordt als ze iets willen verbergen voor hun kind. Je wil het namelijk verbergen voor een specifiek iemand (of groep) en dat de rest het bericht wel begrijpt maakt daarbij niet uit.

Het verschil is toegang voor iedereen behalve ... of toegang voor niemand behalve....

Nogmaals maakt dat uit voor de definitie van encryptie? Aan jouw slotjes analogie te zien wel en moet het altijd gaan om niemand behalve wie de sleutel heeft?

[.oisyn]

emnich schreef op woensdag 10 juni 2015 @ 15:44:
In je vorige reactie schreef je nog dat het niet (makkelijk) leesbaar moest zijn.

Dat bedoelde ik als originele intentie bij het ontwerp van het algoritme, niet of het in realiteit ook niet makkelijk is.

Brent schreef op woensdag 10 juni 2015 @ 15:49:
[...]

Mijn punt is het deel dat je niet quotte Dat de discussie altijd 'filosofisch' zal blijven, tenzij we encryptie opbreken in mathematische en overige encryptie. (althans, dit zou ik een goede splitsing vinden)

Mijn punt is dat je de stelling poneerde dat encoding altijd encryptie is. Daar ben ik het gewoonweg compleet niet mee eens, en dat wat lijkt op een onderbouwing onderschrijft dat punt helemaal niet.

[ Voor 63% gewijzigd door .oisyn op 10-06-2015 17:04 ]

[.oisyn]

Vaan Banaan schreef op woensdag 10 juni 2015 @ 16:44:
[EDIT2] Kenneth hieronder: ja, dat is precies waar ik mee worstelde. Ok ik stem voor encryptie. Waar is de Poll?

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

[gekkie]

*gniffel* .. zo maak je een obligaat grapje ... en zo heb je een topic en een poll

een non encrypted encryption badge .. wat zegt dat nou ... of mis ik nog een diepere encrypted betekenis

[ Voor 45% gewijzigd door gekkie op 10-06-2015 17:20 ]

[.oisyn]

Het is "Grote penis", maar dan encrypted. Toevallig komt er "Encryptie" uit

[emnich]

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

Dat bedoelde ik als originele intentie bij het ontwerp van het algoritme, niet of het in realiteit ook niet makkelijk is.

Maar dat maakt de definitie dus boterzacht. Zo lang iemand maar de intentie had om een encryptie-algoritme te maken dan is het encryptie.

In die zin is Duits, Morse, base64 en een word-document dus géén encryptie.

Daar kan ik me al meer in vinden.

[Brent]

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

Dat bedoelde ik als originele intentie bij het ontwerp van het algoritme, niet of het in realiteit ook niet makkelijk is.


[...]

Mijn punt is dat je de stelling poneerde dat encoding altijd encryptie is. Daar ben ik het gewoonweg compleet niet mee eens, en dat wat lijkt op een onderbouwing onderschrijft dat punt helemaal niet.

Mijn punt is, nogmaals, dat een zinnige discussie over encryptie niet mogelijk is zonder onderscheid in typen encryptie (zoals dit topic demonstreert). Dat onderbouwt uitstekend dat dan encoding makkelijk encryptie te noemen is, en zo ook historisch gebruikt is (Navajo radio-operatoren). Ik noem dat laatste niet slechts codering, want het bereikte het doel, namelijk onbegrijpelijk zijn voor bepaalde mensen op een bepaald moment.

[ Voor 9% gewijzigd door Brent op 10-06-2015 17:38 ]

[incaz]

emnich schreef op woensdag 10 juni 2015 @ 16:53:
[...]

Het punt is dat hier door sommigen ook Duits als encryptie gezien wordt als ze iets willen verbergen voor hun kind. Je wil het namelijk verbergen voor een specifiek iemand (of groep) en dat de rest het bericht wel begrijpt maakt daarbij niet uit.

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.

Maar het verschil is niet:

toegang voor iedereen behalve ... of toegang voor niemand behalve....

Dat is niet de reden waarom Duits geen encryptie is.

(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.)

[ajakkes]

Om de analogie Door te trekken, is een kinderslot ook een slot? Het doel is namelijk gelijk aan het gebruik van Duits als encryptie.

[Brent]

incaz schreef op woensdag 10 juni 2015 @ 17:38:
[...]


Duits lijkt mij vooral geen encryptie omdat het niet uniek reversibel is

Dat is een zeer mathematische benadering, deze eis hoeft helemaal niet universeel te zijn.