Hoi andere anoniem,

Ja hier kunnen opsporingsdiensten wel wat van maken, het enigste wat ze nodig hebben is de key.
Bij deze staat de encryptie en decryptie methode gewoon online en het is ook nog eens javascript ook nog, dit houd in dat iemand deze javascript kan inladen en zo aanpassen dat hij de key gaat bruteforcen.

Gaat wat tijd overheen maar het is een redelijk makkelijke cryptie om te kraken.

Gr. Anoniem

Ik heb het even door de decryptor gegooid.

Er staat dat er binnenkort een nieuwe pc-actie bij een bekende supermarkt is.
Daarnaast wat specificaties over deze pc.

Veel plezier ermee.

@Golem: de gedecrypte code copy-pasten was te moeilijk?

Het is in elk geval geen sterke versleuteling. Als ik de lege regels en spaties eruit haal en het als tekstbestand opsla wordt het 1234 bytes lang. Als ik dat zip, wordt de zipfile 1112 bytes groot, waarvan slechts 966 bytes voor de inhoud (de rest is zip overhead zoals filenaam etc).

Conclusie: er is relatief weinig entropie, meestal betekent dit dat het makkelijk te kraken is (als zippen niet of nauwelijks verkleint is dat geen garantie dat de encryptie degelijk is, andersom meestal wel).

De manier van versleutelen staat gewoon in Javascript op de website, lijkt een beetje op de versleuteling van de berichten in de KLPD CyberCrime challange, niet dat ik zo ver ben dat ik hem zo kan ontsleutelen.

Van de orginele topic plaatser.

Voor: golem
Jammer maar niet waar, want het stukje wat jij plaatst komt voor meter overeen.

Voor: Bitwiper,
Leuk voor de uitleg, echter het bewijst voor mij niet dat jij in dit geval het bericht kunt decrypten.

Ook de tekst van Peter V komt niet eens in de richting.

Ik zal straks wil even de key hier plaatsen zodat jullie het bericht kunnen decrypten en zelf kunnen zien wat er wel
stond. Het stukje wat ik heb geencrypt komt namelijk gewoon van een heel bekende pagina af, en is hot news van een paar dagen terug.


Dus nog meer cryptofreaks hier die denken te weten of te kunnen decrypten wat er staat?

Ik weet een heel KLEIN beetje van cryptografie af, dus daar gaat het niet om vandaar dat ik ook om jullie kennis vraag.
Ik beweer ook niet dat deze vorm van versleuteling super is, maar feit blijft -even- wel dat jullie drie tot nu toe het niet hebben kunnen decrypten.

Dan even wat andere vragen > er bestaan een boel van deze websites waar je berichten kunt encrypten en decrypten. Ik snap dat het op een website encrypten en decrypten niet echt veilig is omdat sites zouden kunnen loggen
wat mensen zoals encrypten en decrypten. Java is er inderdaad een nadeel en sommige websites verplichten je om Java
daarvoor te installeren. Ik zie echter ook websites die zonder Java werken, maar dan nog heb je geen garantie dat ze op de achtergrond de informatie niet opvangen, sniffen of dergelijke.

Vragen die me resten zijn.

Zijn er privacy organisaties die zoiets wel aanbieden in dezelfde vorm op hun pagina die wel zijn te vertrouwen?

Bestaan er applicatie (ik denk dan aan een kleine executable) die op hetzelfde princiepe werkt?
Bericht en key intikken en dan copy/past? Met de sterke versleuteling zoals PGP die heeft?

Voor de duidelijkheid ik weet van het bestaan van PGP voor mail en dergelijke maar dat wil ik niet hebben, ik zoek dus echt een kleine losse applicatie.

Wie weet waar ik zoiets kan downloaden?


Hartelijk dank, en misschien tot strakjes.

Dat vroeg je niet (en bovendien ben ik geen decryptor service, ik heb wel wat beters te doen):
ja, waarschijnlijk makkelijk, ja.

Als ik PGP output (of /dev/urandom, for that matter) naar base 64 omzet, kun jij die zo'n 30% compressen.
En zou je dezelfde conclusie trekken.

Kortom, je analyse hier gaat uit van de veronderstelling dat deze gecrypte text geen lage-entropie overhead bevat zoals binary-to-ascii, framing etc.
Als die veronderstelling klopt is het inderdaad een indicatie van zwakke encryptie, maar *dat* je die aanname kunt maken heb je niks over gezegd.

Je leest niet erg goed, geloof ik, hè?
Zoals Bitwiper terecht al aangaf, je vroeg slechts hoe moeilijk het was die tekst te decrypten,
en Peter V gaf jou (omdat ie net zo min als Bitwiper een decryptor service biedt) een raadseltje terug, voor jou om te decrypten.
Beter proberen te begrijpen wat er bedoeld wordt, dus, topic starter.

Voor topicstarter :
Bewijs maar dat ik het mis heb. :)

topic starter
Hoi klopt mijn fout en ik heb inderdaad te vul gelezen.
Alles wat ik probeer te zeggen is dat als jullie zeggen dat het niet zo moeilijk is dan ga ik ervan uit dat jullie in staat zijn de tekst te doen decrypten. Maar dat is tot nu toe niet echt gelukt.

Zou ik vragen om een wachtwoord hash dan zeggen jullie ook, niet moeilijk en via MD5 hash makkelijk te kraken.
Zijn genoeg sites voor. Vaak hier online gezet met bijvoorbeeld het echte wachtwoord achter een hash.

Ik heb de kennis niet, en bekijk veel topics en berichten dus ga erdan van uit dat jullie een beetje meer experts zijn op dit gebied. Als iemand dan opperd (niet moeilijk) zoals golem doet (die het bericht niet heeft kunnen decrypten) dan vind ik deze encryptie toch wel redelijk. Kijk als de encrytpie niet zo sterk of goed is dan denk ik Hmmm dus niet nemen.

Nu het bewijs voor golem.

De key is:
mI0ETylqIAEEAJ99nT4/I0urPTfWb@/_

Die je dit decryten dan staat er:
Bezoekers krijgen een melding met een verklaring over de actie, maar kunnen daarna eventueel wel doorklikken naar de normale website.

Nadat Stichting Brein XS4ALL en Ziggo aanklaagde, oordeelde een Nederlandse rechter onlangs dat de providers The Pirate Bay moeten blokkeren. De bedrijven legden zich hier niet bij neer en hebben beroep aangetekend, maar in afwachting daarvan moet de website toch geblokkeerd worden.

Ziggo heeft in de nacht van maandag op dinsdag de site al geblokkeerd. XS4ALL volgde de nacht daarop, maar zet dus ook de eigen website op zwart.

Censuur

Volgens XS4ALL wordt door de blokkade ook rechtmatige content gecensureerd. Ook hekelt de internetaanbieder in het opiniestuk dat de getroffen abonnees zich niet kunnen verweren.

Ook hebben ze moeite met het feit dat Brein het aantal te blokkeren IP-adressen en domeinnamen continu mag aanvullen, zo schrijven de advocaten in het opinieartikel.

UPC, KPN en T-Mobile hebben inmiddels ook een brief van Stichting Brein ontvangen waarin de organisatie de bedrijven vraagt de website te blokkeren. Zij hebben dit net als Ziggo en XS4ALL geweigerd en worden nu waarschijnlijk ook voor de rechter gedaagd.


Deze tekst komt van deze site af > http://www.nu.nl/internet/2729223/xs4all-zwart-protest.html

Dus golem????

Bewijs is deze geleverd.

In de tekst van xs4all staat NIKS over:

Er staat dat er binnenkort een nieuwe pc-actie bij een bekende supermarkt is.
Daarnaast wat specificaties over deze pc.

Ik wacht op je antwoord en uitleg.

Ik zal wel proberen om hem te brute forcen ;)

Als de input natuurlijke tekst is, is dit m.i. wle te decrypten.
Het zou mij (een amateur op dit gebied) echter meer tijd kosten dan ik zin heb om erin te stoppen.

Als ik de javascript code van de encryptie site een beetje bekijk is het een soort van Vigenere cipher.
(elke letter wordt verschoven op grond van een letter van het password).

Dat is feitelijk een verzameling Caesar ciphers (letters verschuiven), en redelijk simpel te kraken met frequentie analyse.
De lengte van het password is te vinden op basis van statistiek (index of coincidence), waarna er een reeks losse caesar ciphers over is.

zie http://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher
(en de linken naar Kasiski, Kerckhoffs en Friedman ).

Voor een ciphertext-only attack is dus alleen nodig dat de bron tekst een 'gewone' taal is (of anderszins iets met een bruikbare statistische verdeling), en dat de ciphertekst lang genoeg is om die statistiek te gaan zien.

Kortom, demo'tje van javascript, huiswerk voor een basis practicum cryptanalyse maar voor meer is het niet geschikt.

Kijk eens naar Cryptool

CrypTool is an open-source Windows program for cryptography and cryptanalysis. It’s the most wide-spreaded e-learning software of its kind.

http://www.cryptool.org/en/

Of BASE64 zo goed comprimeert weet ik niet, maar je hebt wel gelijk!

Ik heb ooit eens ergens gelezen dat je zo de sterkte van encryptie kunt inschatten, maar nu ik er (door jouw terechte opmerking) over nadenk is dat onzin. Stel je met AES256 degelijk versleutelde random data voor, en voeg tussen elke 2 bytes 10 spatie-bytes toe. Het resultaatbestand zal inderdaad uitstekend comprimeerbaar blijken terwijl er toch sprake is van uitstekende versleuteling. Weer wat geleerd, dank voor deze les!

Nee, dat is niet de key, dit moet zijn:
De tekst bovenaan deze pagina klopt trouwens ook niet, maar daar kun jij niks aan doen. Dit komt doordat security.nl spaties aan het begin van een regel verwijdert (en hoewel in het huidige geval niet van toepassing, meerdere spaties achter elkaar in 1 enkele verandert). Helaas lukt het mij niet om de "versleutelde" tekst in een "code" statement op te nemen doordat er bakhaken in staan.
Als je de tekst uit mijn volgende bijdrage plakt in http://www.seabreezecomputers.com/encrypter, en vervolgens de € vervangt door een spatie, kun je de tekst wel goed decoderen.

rwb}#H5G&*y!s}NL@=GW?2Us*A9Cy*{s~3LL@=XWC}To0F><2y%s|3KLQ~Ef:ws.
+>1G2u$|xxUf6~Cd?sgs4B>I(osz*+LSQ"QaC}Tw)H5C2xoo|3KLQ,Qd>sTs=
T57&s#s8

aHK32aEE{Kv2F><2L!ss"f?%Q#>|2M|=79<yy.ok"RS3~IV6>g}-O4:wvrs*xLUQ
kGV6%To,AC:2|sqr(LYQ-P^2!O"=A1I2ns.z&V];"GdD2<v#\ >%k#s*UH`Q
+QWEwV. I?@}o!sxAf+7=DW5%Qx4B>T~ouro"fa;!Jq9{M!=K9:'*pwt3UL70aW?2
Ps ?5C2ls!yxWf3~PY6'My#K4`2woo|3PUQ~Hi2uP#'K7Tvko!!tUf?-GfPvM.
5B2H{~s.~#JOQ%GT="Sy#BB92"}!nxUt

,'IY@2Ps#CDT{x.ro3UH5&VqGsV.+>1Cvku.y$fK;,UV2ygr#\C>'o.ov3
NL4*Q]<wM!"jO-e>OZV3]V>%FWPvM.,>3='*rok&VW]=OS2%g)#QO9(}.}y~fK7=
G[8wV.5B2H{~s.y$faI~Tf^

UM|1REG

hyzuo"Zf*pu3|^g&-O4I2n}}|3KLQ Na<}Ir#\?D}*!sm{[T32KY62K},Q5C'*
usmxUZG0GWCvu.lL;Tzoysv(fK7=K`EwZ|#Q16!lwsnxYf;,aZ6'g}.F>>w}#$u3
KHF=FWPyM#0L6;wx.ol#UU7#UqK{Kv=K9:'*y$x"LUQ4GdHwZs,j

~D}*vsluLUQ8Gq>"Mw2BOBw~.vo(fM7'Vq5s\._O5>!*vs~3HH@2C^P'M.
€I?@}o!sx307^~Fd6&[s,\5C2n}{o|UU3+G`PuW|2F>J2wou*tHUH3N^6!s.8LO
Hur!wt*LUQ"Gq2v^}!>D:!*w|*{L[Q-R[?{Mo0Q9@wv<

cZVrf|m0q6!gbJ*?7{vs.rxII7,a[? Qr"B<H2y}y*xLUQ T[6xg%~KO
('sqv~|UNQ_TW:!g},QF6!qs|*+HHD'Pq5wg}0D1C{}o#sxfK7=DW5%Qx4B>T
)|ooq(fK7=YW3&Q##\D:2lz}u~LY7,oq+{R.&B27wx.rs(fU72aS=&gh'D7D2o|.
bfz(}iaY6*Mw%BB92o|."#YK7,a`F2_o~OC8zsx|v|QRQ-Q]P)W}0\4:2|sqr(LYQ
%GV2sOrK

Hoewel ook ik geen cryptograaf ben weet ik, na wat tests met wachtwoorden in input, en door het bekijken van de source, wel zeker dat dit crapto is en geen crypto. Dat wil echter niet zeggen dat ik elk stukje tekst ook in korte tijd kan decoderen, maar de kans dat een cryptograaf met de juiste tools dat kan is groot.

Goede cryptografie kenmerkt zich erdoor dat er zoveel permutaties op je plaintext zijn dat het, ook met volledige kennis van het algoritme, je op brute force bent aangwezen zonder dat met aanwijzingen (zoals hierboven genoemd) kunt bespoedigen. De sleutellengte kies je bij de toepassing zodanig dat de naar verwachting benodigde tijd en/of geld de poging tot brute-forcen niet rechtvaardigen.

Waarom is jouw voorbeeld geen goed crypto?
- Er is (bijna) een 1-op-1 relatie tussen de leesbare en "versleutelde" tekst. Voor het mooie worden op het einde van regels versleutelde tekst een "¶" teken geplaatst (dat wordt genegeerd bij decrypten).

- Er is een 1-op-1 relatie tussen de karakters in het wachtwoord en de karakters in de tekst. Na de laatste letter van het wachtwoord gaat het algoritme weer terug naar de eerste letter. Dus de derde letter van het wachtwoord heeft effect op het derde karakter van de tekst, en als het wachtwoord 10 karakters lang is, ook op het 13e, 23e etc. karakter in de tekst.
Een bijwerking hiervan is dat "1234" hetzelfde wachtwoord is als "12341234" en omgekeerd.

- Door het vorige weet je dat uitsluitend het eerste karakter van het wachtwoord het eerste karakter van je versleutelde tekst beïnvloedt. Als je ervan uitgaat dat het eerste karakter een hoofdletter is, is het aantal mogelijkheden beperkt.

- Niet alle tekens worden versleuteld: bijv. éëè en € blijven gewoon "op hun plaats" als plaintext.

- Normaal gesproken eindigen regels met een punt. Daarnaast kan http://en.wikipedia.org/wiki/Frequency_analysis van pas komen bij het ontcijferen van dit soort teksten. Zie ook de reactie van Anomiem, 2 feb 17:18.

In de tabel hieronder zie je het effect van de "versleuteling". De bovenste regel (achter K¦) geeft de mogelijke tekens in het wachtwoord weer. In de linker kolom staat de plaintekst (ik toon alleen a..z, lang genoeg zo), in de matrix daaronder/naast het "versleutelde" karakter. Dus een plaintekst "a" zal met wachtwoordkarakter "A" tot een "k" leiden etc. En het wachtwoord "ABCDEF" met de tekst "aaaaaaaaaaaa" leidt tot "klmnopklmnop".

Affijn, dit versleutelingsalgoritme is, met wat "quirks" (rechts in de tabel) een per-plaintekst-karakter-ROT-operatie afhankelijk van het "actuele" karakter in het wachtwoord. Dit kun je nauwelijks versleutelen noemen.

PS de tabel is niet helemaal zichtbaar maar "hij is er wel". Als je alle regels selecteert, kopieert en plakt ion kladblok, zie je de volledige breedte (97 karakters).

Als je sleutel even lang is als je bericht, is het zowat een OTP http://www.interhack.net/people/cmcurtin/snake-oil-faq.html#SECTION00057000000000000000. Als dan meerdere berichten met dezelfde sleutel zijn vercijferd, is de encryptie triviaal te breken.

Iets anders gebruiken als AES of TripleDES is natuurlijk allemaal snake-oil tegenwoordig. Hoef je eigenlijk niet eens meer naar te kijken. Tenzij je dat leuk zou vinden :-)

LOL
En zo is de cursus "hoe kom je door de encryptie" beeindigd. :)

Val de zwakste schakel aan, niet de encryptie.

Ik moest echt lachen toen je mijn eerste commentaar serieus nam.

(ben de anoniem , do 15:19 , en do 17:18))
Base64 gebruikt een alfabet van 64 tekens (6 bits) om octets (8 bits) weer te geven. Vier karakters om drie bytes weer te geven, dus een overhead van 33% , die je bij compressie naar een binair formaat minimaal moet kunnen terugwinnen.

Wat je gelezen had was grosso modo ook wel juist, vandaar mijn caveat dat je alleen wel moet weten of er geen overhead met duidelijke redundantie is toegevoegd aan de encryptie.

Want normaal gesproken verwacht (en eis) je inderdaad van een goede encryptie dat de (pure) output statistisch niet te onderscheiden van random. Oftewel, niet te compressen.
Inderdaad kun je iets definieeren zoals jij aangaf, met veel voorspelbare karakters tussen de 'echte' crypto output en het geheel zal dan niet random zijn.
Nu zijn er ook wel betere statistische toetsen voor 'random' dan zip/gzip/bzip , maar het is zeker een 'red flag' als "crypto output" behoorlijk te compressen is , in elk geval nadat je gekeken hebt of het niet om allerlei transport enveloppen (zoals base64, headers o.i.d gaat waar de winst vandaan komt).

Kortom, een 'goed zipbaar' is een quick en dirty, maar niet totaal foute eerste test om padvinder encryptie van "iets beter" te onderscheiden.