Posta era ondske koder och kryptos här!

Antag att du har en krypterad JPG-fil. Antag även att filnamnet på något sätt avslöjar att det är en JPG-fil. Plötsligt vet en attackerare hur headern ser ut i plaintext. Vissa saker måste finnas i headern på vissa platser, och vissa saker kan bara vara vissa värden.

Så det är en tämligen svag kryptering på många sätt och vis.

det enda krypto jag implementerat är RSA, men riktigt stora primtal är väll den i princip omöjlig att knäcka med dagens datorkraft??

Det sägs så, jag läste en bra bok om kryptering för flera tag sedan, tror den hette kodboken eller nått sånt. Skriven av simon singh. Den var skitbra och tog upp alla möjliga krypteringsalgoritmer på ett mycket lättläst och lättförståligt sätt. Rekomenderas varmt till alla som vill sätta sig in och vill få en mjukstart i kryptering. Där påstås det att RSA är helt säkert vill jag minnas. Han tillägger dock att det funnits ett hundratal andra krypteringsalgoritmer som varit "helt säkra" genom årtusendena

RSA bygger på att våra datorer inte kan faktorisera stora komposittal (primtal * primtal) inom en rimlig tidsram. Dock kan kvantdatorer göra detta. Inte för att det är så farligt, eftersom att när kvantdatorer verkligen kommer så har vi ändå kvantkryptering.

Sedan skulle det även (men är kanske inte särskilt troligt) kunna komma något matematiskt genombrott, så att någon hittar en metod för att faktorisera stora komposittal i polynomialtid, vilket också skulle vara ett stort hot mot RSA-kryptering.

Kodboken av Simon Singh som Delight nämnde är en bra bok.
Om man vill bli lite mer teknisk är Applied Cryptography av Bruce Schneier också en bra bok.

jag gillar RC4-kryptering. Själva RC4-algoritmen är egentligen en generator fär pseudoslumptal, dessa kan man t ex xor:a med det som skall krypteras. Värt att tänka på är att i början kommer det inte så slumpmässiga tal så kör ett gäng loopar före du börjar använda dina tal.

EDIT: RSA har en mycket stor fördel över de flesta krypterings algoritmer, man kan kryptera om man bara har produkten av nyckeltalen. Altså mycket säkrare i vissa fall

Kolla min förrförra post, är det RC4?

[QUOTE]
EDIT: RSA har en mycket stor fördel över de flesta krypterings algoritmer, man kan kryptera om man bara har produkten av nyckeltalen. Altså mycket säkrare i vissa fall [/QUOTE]

Huh?

Docksider: det är väll i princip omöjligt att skriva ett säkert krypto där användaren har tillgång till den fysiska applikationen... Nånstans måste ju lixom nycklarna sparas...

edit: vilken metod för att hitta stora primtal har ni använt i era RSA implemenentaioner??

Jag har aldrig själv valt primtal för säkerhet, bara demonstration.
Det finns uttryck som alltid är primtal och är lätta att använda för att räkna ut stora primtal, använd dock inte sådanna. Om jag skulle försökna knäcka ett RSA krypto skulle jag börja med sådanna tal. Jag skulle istället bestämma mig för ungefär vilka tal jag vill ha och sedan prova när belägna tal och testa dessa fullständigt. Jag tror mig ha läst att dett finns bättre och sämre primtal för RSA, värt att kolla upp.

Om nyckeln ligger någonstans på disk, i programfil eller någon annanstans går den alltid att få fram. Fördelen med RSA är att det är bara den offentliga nyckeln som går att finna och den duger bara till kryptering.

Nu var det ett tag sedan jag pysslade med RSA, men jag fick en idé när jag läste Kodboken av Singh. Borde inte det gå att göra en variant på Rainbow tables för primtalsprodukter? Dvs man slår primtalsprodukten i en stor databas och får ut vilka primtal den består av. Finns det något sådant redan eller är det något problem med det jag missat?

Problemet med rainbow tables är att de skulle ta upp massor med plats. Dessutom tar det relativt lång tid att avgöra ifall ett tal är ett primtal eller inte.

Antag att vi har en RSA-nyckel på 512 bitar (vilket ändå är ganska lite). Detta motsvarar 64 bytes. Sedan multiplicerar vi nyckeln med en lika lång, då får vi 4 KiB. 10000 olika kombinationer till vår rainbow-table, vilket ändå är en väldigt liten tabell, eftersom det ändå bara använts 100 olika primtal då (om jag inte räknat fel) skulle således ta upp 39 GiB.

Och detta är ju bara för 512-bitars RSA-nycklar. Vanligtvis kör man ju med minst 1024 och ibland upp till 4096.

Äsch, man får köpa fler hårddiskar och packa lite, eller vänta på framtiden

Det där måste jag räkna på hur stort det blir, om man kan göra sk "rainbowtables" för 4096 RSA faktorisering på på ett acceptablet antal TiB är jag säker på att folk med lite resurser har sådanna. Då kommer inte jag lita på RSA igen =/

hur är det nu igen... nycklarna ska väll vara relativt prima för att det ska vara opimalt.. eller var det tvärt om? var ett tag sedan jag pysslade med RSA....

finns en mattematiker som forskade typ 30 år primtal och lade mer eller hela grunden till RSA genom sitt misslyckandes. Han försökte att devisa att man kunde systematiskt primtalfaktorisera ett tal, vilket man inte kan. Visst man kan använda sannorlikeheter och liknade (Rainbow) men när nycklarna är så stora går det inte att använda.

Jag postade dels en vanlig xor, men oxå en variant som jag hittade på själv för massa år sedan:

RandomSeed = $DEADBEEF; //<--min nyckel

for i = 1 to length(minText) do
minText[i] = minText[i] XOR (Random AND $FF);

Genom att seeda slumpgeneratorn med samma tal hela tiden få man ju samma serie ur slumpgeneratorn

Nja. Nycklarna består av två tal.

http://en.wikipedia.org/wiki/RSA

Läs där.

RandomSeed = $DEADBEEF; //<--min nyckel

for i = 1 to length(minText) do
minText[i] = minText[i] XOR (Random AND $FF);

Oj, det missade jag, RC4-algoritmen är i stortsett in slumpgenerator som du kan välja en fras att börja på sedan tar man ut ett bestämt antal värden innan man krypterar/dekrypterar.

Du inser att det är lite fel att kalla det för en slumpgenerator, eftersom talen som genereras inte är slumpmässiga? Du KAN säga att det i stort sett är en pseudoslumptalsgenerator, eftersom dessa använder deterministiska algoritmer.

Om du trycker in en seed i den det där "kyptot" så blir det en ganska effektiv dokument förstörare

Har för tusan också gjort ett enkelt krypteringsprogram. Använder det för att spara inloggningar till alla hundratals forum man är medlem i. Programmet är skrivet i C#.NET och MD5-hashar en nyckel som användaren skriver in. Sedan körs en vanlig XOR operation mellan den hashade nyckeln och texten användaren vill kryptera. Vet att det inte är någon jättesäker kryptering men det känns som att det duger åt mig, vad tror ni om säkerheten?

http://www1.shellkonto.se/nissee/kryp/

Ps: Är en glad amatör och programmet har nog någon bugg eller fem.

Kanske inte så ondskefullt, men detta är vad min hjärna fixade fram för useless utility på nått DH för ett par år sen

fulpack.php

#!/usr/bin/php
<?php
        $ones = 0;
        if ($argc == 1)
        {
                echo "fulpack usage: simply like this:\n\tfulpack filename compressedfilename \n\twill create a fulpack compressed file\n";
                die;
        }
        elseif ($argc == 2)
        {
                echo "d0h!\n";
                die;
        }
        elseif ($argc > 3)
        {
                echo "Don't waste my time!\n";
                die;
        }
        if (!is_file($argv[1]))
        {
                die ("I'm a BANANA!\n");
        }
        $file = dio_open($argv[1], O_RDONLY);
        $file_cont = dio_read(dio_open($argv[1], O_RDONLY), filesize($argv[1]));
        dio_close($file);
        $blah = preg_split('//',$file_cont,-1,PREG_SPLIT_NO_EMPTY);
        foreach($blah as $b)
        {
                $ettor = preg_split('//', decbin(ord($b)),-1,PREG_SPLIT_NO_EMPTY);
                foreach ($ettor as $ett)
                {
                        settype ($ett, "integer");
                        if ($ett == 1)
                        {
                                $ones++;
                        }
                }
        }
        $md5 = md5_file($argv[1]);
        $fsize = filesize($argv[1]);
        $w = array (0 => $fsize, 1 => $ones, 2 => $md5);
        if (is_file($argv[2]))
        {
                echo "Lets eat some lego!\n";
                die;
        }
        $fp_file = fopen ($argv[2], "w");
        foreach ($w as $wr)
        {
                $wri = $wr."\n";
                fwrite($fp_file,$wri);
        }
        fclose($fp_file);
?>

fulunpack

#!/usr/bin/php
<?php
        srand(date("s"));
        if ($argc != 3)
        {
                echo "My SPOON is to big!\n";
                die;
        }
        if (!is_file($argv[1]) || is_file($argv[2]))
        {
                echo "M-O-O-N, that spells YOUAREADUCK!\n";
                die;
        }
        $file = file_get_contents($argv[1]);
        $korv = split ("\n", $file);
        $size2 = $korv[0];
        $ones = $korv[1];
        $md5 = $korv[2];
        settype($size2, "integer");
        settype($ones, "integer");
        $size = 8*$size2;
        $mdkorv = "";
        echo "Trying to unpack.\n";
        $try = 0;
        while ($mdkorv != $md5)
        {
                $val = array();
                for ($i = 0; $i < $size; $i++)
                {
                        $val[] = 0;
                }
                $kossa = true;
                $c = 0;
                while ($kossa)
                {
                        $ap = mt_rand(0,count($val) - 1 );
                        if ($val[$ap] != 1)
                        {
                                $val[$ap] = 1;
                                $c++;
                        }
                        if ($c == $ones)
                        {
                                $kossa = false;
                        }
                }
                $boll = implode ("", $val);
                $balong = array();
                for ($i = 0; $i < $size2; $i++)
                {
                        $balong[] = chr(bindec(mb_substr($boll,8*$i, 8)));
                }
                $final = implode("",$balong);
                $io = fopen($argv[2], "w");
                fwrite($io,$final);
                fclose($io);
                $mdkorv = md5_file($argv[2]);
                $try++;
        }
        echo "$try tries needed to unpack.\n";
?>

Texten är rysligt liten. Vad gör koden?

Komrimerar en fil m.h.a md5, storleken och antalet ettor i filen.
Packar upp genom att slumpmässigt skapa en fil av rätt storlek, rätt antal ettor och sedan kör md5summa tills den hittar rätt
Kan tillägga att den skriver filen varje försök oxå

Aha, najs. Jag byggde ett liknande program en gång: roten-ur-komprimering.
Man tog tex 16 byte data, tog roten ur talet det motsvarar, sparade som 8 byte. Man sparar även en checksumma på ursprungsdatan (som då måste vara < 8byte för att man ska spara plats)

Sen vid upppackning så testar man checksumman på alla 16byte-tal mellan x^2 och (x+1)^2, och stannar när man hittar rätt (vilket såklart tar hiskelig tid).

Vill man slippa problem med tappad data får man även i nedpackningen testa alla möjliga fall och tex räkna antalet gånger som checksumman ska bli rätt innan man nått rätt tal.

Raz, hur bra komprimerar den där?
http://en.wikipedia.org/wiki/Comparison_of_file_archivers#Com...

Nått extremt
t.ex en fil på 4GB som innehåller enbart 1:or
md5-summan kommer bli 32B stor.
antalet ettor = storleken*8 = 34359738368 stycken, 11 tecken = 11B som ska sparas + storleken, 4294967296, 10 tecken = 10B
så den komprimerade filen kommer vara 32+11+10+1 (md5 + 1:or + storlek av orginal + eof) = 54B
så från 4GB -> 54B
ganska extrem komprimering dvs
Problemet nu är uppackning, första ska man slumpa fram rätt fil av en storlek på 4GB tills man får rätt md5-summa, sen är md5 vad jag förstått en envägsalgoritm, så chansen finns att det finns, även om liten >1 fil på 4GB med rätt antalet ettor (kanske inte i detta fall) som har samma md5summa (om jag har fel får någon rätta mig), så att packa upp en 4GB stor fil packad med fulpack skulle kunna ta hundratals år

När jag testade programmet anände jag en fil på 2 tecken + eof, dvs 3B stor, vilket tog mellan 100 och 10000 försök att packa upp, en fil på 4B kunde ta upp mot en miljon försök att få tillbaka, lite onödigt då orginalfilen är 3B och den packade blev 38B

Ugh
När vi om hundra år har maskiner som klarar att göra det där snabbare kommer du vara en hjälte inom komprimering

Nä, folk blir nog inte så glada om de inte är garanterade att få tillbaka rätt fil

Nej det har inte tagit mig ett år att komma på ett svar, såg att tråden hade necrobumpats så jag tog en titt 8).

Nej jag anser inte att det är en slumpgenerator, ärligt talat anser jag att slump är befängt och inte existerar, t om nuklärtsönderfall sker enligt ett mönster, inte förutbestämt eller möjligt att upprepa då det finns faktorer kvar sedan universumskapande. Förekomsten av slump är lika troligt som magi och högre väsen i min mening.

EDIT:

Det där kommer vara brukbart när vi får kvantdatorer hehe, bara man typ tar och lägger till var miljonte täcken så kommer man ha data till att ursilja den rätta datan från de med samma hash