Krypteringsprogram - Presentation av Projektarbete

Permalänk

Krypteringsprogram - Presentation av Projektarbete

Hej!
Vi håller just nu på att slutföra vårt projektarbete som inriktar sig i symmetrisk kryptering, och vi tänkte att ett festligt sätt att presentera det på vore att publicera det här, samt att ge en liten utmaning.

För att kolla säkerheten på själva algoritmen kom vi ej på något bättre sätt än att publicera det här på sweclockers, där folk med hyffsad kunskap om detta (troligtvis bättre än oss) har möjlighet att prova på att knäcka vårt algoritm.

Jag börjar med att presentera kryptotexten:
http://www.xtremegamers.se/kryptotext.txt
Notera att texten är i unicode.

Samt programmet som du kan hämta: HÄR

Programmet kräver Java Runtime. Vi är även tacksamma för konstruktiv kritik samt allmän feedback.

Happy hacking, vinnaren får golfklapp

Visa signatur

[AMD Athlon64 4400+ ][Geforce 8800GTS][ASUS M4N-SLI]
[3x300gb i RAID0, 500 gig och en 74gb raptor = 1474 GB]

Permalänk
Medlem

Alltså, vad är meningen med denna tråd egentligen? Hur kan man testa säkerheten hos en algoritm genom att försöka bruteforcea en "krypterad" text?
Ni verkar ha missuppfattat hela poängen med en säker krypteringsalgoritm.
Vill man veta hur säker en algoritm är så utför man en kryptoanalys av den, vilket kräver att man har tillgång till själva algoritmen.
Det ni verkar göra är att köra med "Security through obscurity".
http://en.wikipedia.org/wiki/Security_through_obscurity

Permalänk

lösenordets MD5-summa uppdelat i 32 är cykeln som förskjutningarna sker i.
Meckat ihop ett litet diagram som visar på ett förståeligt sätt hur det funkar här (docx). Givetvis uppmuntrar jag alla andra metoder än brute-forcing, gör det här mest för att få överblick om hur pass säker vår metod är.
Förövrigt är det hela inget komplicerat, bara enkla förskjutningar som sagt

Visa signatur

[AMD Athlon64 4400+ ][Geforce 8800GTS][ASUS M4N-SLI]
[3x300gb i RAID0, 500 gig och en 74gb raptor = 1474 GB]

Permalänk
Medlem

Ok, lite snabb analys på det hela.
Det ser ut som att ni implementerat Vigenere-kryptering med en fix nyckellängd på 32, där själva nyckeln bestäms genom MD5-hashning av lösenordet.
En trevlig tanke med lite twist i
Vad jag ser så finns det vissa risker ... då ni shiftar en in-symbol ett visst antal steg så adderar ni med nyckeln bara, där finns en risk att ni adderar för stora tal. Tänk om den nyckeldel ni ska addera är lika med största talet en int kan innehålla, vad händer då?
Vidare så är Vigenere inte säkert, speciellt inte då man vet vad nyckellängden är... I ert minimala testfall så hade ni 36tecken, vilket nästan är lika med nyckellängden vilket i stort sett är ekvivalent med ett Wernam-schiffer (nyckellängd = klartextlängd) detta är ett säkert kryptosystem men inte användbart för större datamängder.
Det finns många fina statistiska attacker mot Vigenereliknande krypton om man har "tillräckligt" stor kryptotext.
Vidare så är kryptot inte säkert mot Chosen Plaintext Attack (CPA) eller CCA1, CCA2.

Visa signatur

weeeee

Permalänk
Citat:

Ursprungligen inskrivet av mounte
Ok, lite snabb analys på det hela.
Det ser ut som att ni implementerat Vigenere-kryptering med en fix nyckellängd på 32, där själva nyckeln bestäms genom MD5-hashning av lösenordet.
En trevlig tanke med lite twist i
Vad jag ser så finns det vissa risker ... då ni shiftar en in-symbol ett visst antal steg så adderar ni med nyckeln bara, där finns en risk att ni adderar för stora tal. Tänk om den nyckeldel ni ska addera är lika med största talet en int kan innehålla, vad händer då?
Vidare så är Vigenere inte säkert, speciellt inte då man vet vad nyckellängden är... I ert minimala testfall så hade ni 36tecken, vilket nästan är lika med nyckellängden vilket i stort sett är ekvivalent med ett Wernam-schiffer (nyckellängd = klartextlängd) detta är ett säkert kryptosystem men inte användbart för större datamängder.
Det finns många fina statistiska attacker mot Vigenereliknande krypton om man har "tillräckligt" stor kryptotext.
Vidare så är kryptot inte säkert mot Chosen Plaintext Attack (CPA) eller CCA1, CCA2.

vid klartext så är det osannolikt att något skrivet tecken skulle ha ASCII-position (där förskjutningarna sker) större än 240 (255-15), däremot vid filkryptering borde det vara en annan femma. Dock funkar det till min förvåning, trots att det kanske inte är världens snabbaste filkryptering

Visa signatur

[AMD Athlon64 4400+ ][Geforce 8800GTS][ASUS M4N-SLI]
[3x300gb i RAID0, 500 gig och en 74gb raptor = 1474 GB]

Permalänk
Medlem

"osannolikt" är sådanna ord som inte får användas. För att du ska kunna använda en algoritm, t.ex. SNOW (3G-telefoni) så måste man kunna lita på den till fullo, man måste veta vad som händer oavsett vad som stoppas in.

Visa signatur

weeeee

Permalänk

testat med förskjutning av ASCII-tabellens högsta tecken, och det ger bra utslag vid kryptering även vi förskjutning av F (15). Om detta skulle vara specifikt för windows är av intresse, jag ser gärna någon med annat operativsystem testa detta, min server saknar tbord och skärm

Visa signatur

[AMD Athlon64 4400+ ][Geforce 8800GTS][ASUS M4N-SLI]
[3x300gb i RAID0, 500 gig och en 74gb raptor = 1474 GB]

Permalänk
Medlem

har du testat något lösenord då md5-hashningen genererar största int-värdet?

Visa signatur

weeeee

Permalänk

då MD5-hashens hexadecimala tecken behandlas var för sig så borde enkel kryptering av högsta tecknet i ASCII-tabellen med ett F som nyckel ge det största möjliga värdet, och det funkar hur bra som helst från vad jag kan se

Visa signatur

[AMD Athlon64 4400+ ][Geforce 8800GTS][ASUS M4N-SLI]
[3x300gb i RAID0, 500 gig och en 74gb raptor = 1474 GB]

Permalänk
Hedersmedlem

Ett vanligt sätt att undvika problemet är att använda xor istället för att bara addera.

Permalänk
Medlem

eller använd addition under en ändlig kropp (vilket är vad XOR är om kroppen är Z_2)

Visa signatur

weeeee