Hejsan

Jag har nyligen blivit klar med ett program som gör att man kan spara information krypterat.
Själva programmet har jag gjort själv men krypteringsalgoritmen är lite äldre än mej (den ansågs oknäckbar i 300år). Krypteringen är inte helt oknäckbar, men jag tror att den är tillräckligt säker för oss som inte har kryptologer som fiender...
Om du väljer en krypteringsnyckel som är helt slumpmässigt vald och längre än meddelandet finns det bara ett sätt att knäcka det: att testa alla möjliga nycklar, vilket skulle ta lång tid utan kvantdator...

Tyvärr har jag inte lyckats perfekt med att göra programmet användarvänligt men jag tror att ni kommer fatta hur det ska användas. Dessutom kan det finnas någon bugg här och där. På hemsidan finns det mer info (bl.a. hur jag kom på namnet på programmet).

Klicka först här sedan på "Mina program" och sedan på "CryptoCow 2.0".

Ha så kul!

Trevligt initiativ. Kreativitet skall alltid premieras. Därför kommer här lite konstruktiv kritik.


Hellre än att skriva så så bör du erbjuda två versioner av programmet. En där .NET Redistributables finns med och en utan. Att kräva att anvndaren själv utför vissa steg manuellt innan programmet kan användas är att ge användbarheten en spark i skrevet.

Det finns andra sätt att fixa detta. Typ använda Windows-registret eller att lägga sådana filer i Documents and Settings\<användarnamn>\Application Data.

Detta är en allvarlig brist i programmet. Du bör överväga om at ens skall ligga ute så länge detta fortgår. Det ger att dåligt intryck.

Hmm... detta låter lite väl svagt i ärlighetens namn. Och vilken kryptoalgoritm är det förresten du användeR? Jag hittar itne det någonstans. Detta behövs för att 1) den som vill knäcka det kommer på det ändå 2) för att användaren skall kunnn granska ditt program och via detta känna trygghet i dess säkerthet. I sådana här sammanhang är det ganska vitkigt att vara öppen och säga "Så här har jag gjort" om man vill att användaren skall kunna lita på programvaran.

Ltie för familiärt och avslappnat. Det ger ett mindre bra intryck. Ett städat och korrekt språk är ett krav om man vill bli tagen på allvar.

Et ttips om du vill ha idéer för hur funktionaliteten i dit tptogram kan bli ännu bättre föreslår jag att du Googlar på "Privacy Software" så kan du se hur andra har gjort och plocka russinen ur kakan.

Lycka till.

/J

Tack för att någon överhuvud taget svarar i min tråd och tack för tipsen!

Jag är ärligt talat osäker på hur detta skulle göras. Men visst, en spark i skrevet på användarvänligheten. Men, om jag inte minns fel ska .net framework följa med nyare versioner av Windows...

Jo, det här ska vi nog fixa...

Det här är lite svårare. Mitt program funkar så att det läser in filen på samma sätt som om man öppnade den i "Anteckningar", denna text krypteras sedan. Sedan dekrypteras detta tillbaks till den text som man skulle se om man öppnade filen i Anteckningar. Det här systemet förutsätter att man kan öppna en fil (vilken filändelse som helst) i Anteckningar, kopiera innehållet, klistra in det i en annan fil med samma filändelse och sedan skulle man ha en kopia av den ursprungliga filen. (Jag hoppas att du förstår hur jag menar)
Problemet är att detta inte ger läsbara filer. Prova själv med t.ex. en bild.

Jo det är kanske inte det bästa, jag får väl komma på något, förslag?

Jo, nog allt ska jag kolla lite. När mina kompisar hade testat programmet och sa att de var nöjda med användarvänligheten tyckte jag att det fick duga.
Som lite kuriosa kan jag nämna att min programmeringslärare flera gånger sagt att alla programmerares största fiende är användaren. Jag fattar vad han menar...

Vad menar du med svagt?
För själva krypteringen använder jag Vigenère-chiffret (nej, jag kan inte heller utala det). Men istället för att bara använda alfabetets tecken använder jag alla tecken i ASCII-tabellen.
För mer inf om Vigenère-chiffret:
http://sv.wikipedia.org/wiki/Vigen%C3%A8re-chiffret
Jag har funderat på det, men jag tänker inte lägga ut källkoden, risken finns att någon kopierar...

Jag ska nog också tilllägga att jag, som gymnasieelev, inte hade tänkt konkurrera med kommersiella produkter...

Can du posta koden du använder för inläsning? Lägg [ code ] tags om den


Nej. Inte namnet... utan att du skriver "...hur fan jag...".


Ah ok.

/J

Programmet är skrivet i Visual Basic .NET 2005. Funktionen för att läsa filer är en av all "inbyggda" funktioner i vb nämligen StreamReader som används på följande sätt:

deklareration av läsare:

användande:

sedan måste läsaren "stängas"


Det är denna funktion jag använder, som du ser, returnerar den en strängvariabel med värdet på ett tecken i filen som sedan krypteras och sparas i den krypterade filen. När läsare.read utförs igen läses nästa tecken in. Detta loopas tills alltså tills hela filen är inläst och krypterad.

Fixat!

Förresten, när jag läste igenom ditt första inlägg igen kom jag en till sak: Vad betyder "premieras"?
(man lär sig många nya ord på det här forumet )

Efter några minuters läsande om Vigeneré chiffer.



http://www.99mac.se/ovrig-programvara/2593...terad-text.html

Att öka antalet tecken kommer mest bara öka tiden från sekunder till minuter...

Jaha, var så god:

ÀÁØ‘Mà‘ؤ–??’Å¢u¦¿MßãÕèÍçÚÖÒ?’’—¢£LØ[žu¥º”yy¯äÇÖßÜ×ßÙL¡??LÚÍš¹³²MÙØÍ–ÎVãˆÒÖæL˜›Ÿ×ÖL¾a¾–àã†ÞÊVãÜÏ~|r?–?Ö„?Ëa¶›ŒâÚåÒÞçÑÜÕ’š—££LáÇ”u¥²”yy®[Ò‘×ÑÜßåL˜?¡?’È¡u°´•ŒÙÇÝŒ‘àËÖ‘Ö‘ªO›–ç×LÈ°¾MÔØÓâÅß‘ÔSÞà?ªOš¢ÓÖ

Jag ska nog också lägga till att jag, som jag redan sagt, inte menar att jag ska konkurrera med kommersiella krypteringsmjukvaror och att jag inte heller hade som mål att mitt program skulle överlista någon som har någon professionell erfarenhet av kryptering, dom är trots allt rätt duktiga på KTH...

För att det skall ta sekunder måste man trots allt veta hur eländet är krypterat. Nu har jag inte läst kryptografi, eller ens algebra (som jag förstått är en grundkurs till kryptografiämnen) så, nej jag är inte ärkebäst på detta, dock så gör jag just nu en coprocessor för kryptering så lite koll har jag.

Åtminstone gäller för mig att när jag ser ovanstående rad inser jag inte snabbt om det är MARS, Magenta, Two-fish eller Vigenère.

Det finns ett fritt program som heter crank som gör underverk med sådana där chiffer.

Okej, jag har inte testat det där programmet men eftersom den krypteringsalgoritm (Vigenère) jag använder går att forcera (klicka här och läs under "Cryptanalysis") om mängden krypterad text är tillräckligt stor, får vi nog utgå ifrån att sådana program fungerar.

Om man däremot skriver en kort fil som innehåller t ex lösenord (som naturligtvis inte är hela ord utan istället bstår av massor av olika tecken) och använder en lång nyckel, får man ett tämligen svårknäckt krypto.
Det går att testa alla olika nycklar, men det tar tid. Antalet möjliga nycklar är lika med 255 upphöjt till nyckelns längd. Vi tar ett exempel med en nyckel på 7 tecken:
255 ^ 7 ≈ 7,0 * 10^16, vilket är fler än antalet sekunder på 2,2 * 10 ^9 år (vilket i sin tur är mer än en tiondel av universums nuvarande ålder, man får inte vara stressad...).

Men om nu användaren skriver ett längre meddelande, på vanlig svenska, kan man knäcka kryptot (läs på sidan jag nämnde tidigare), har någon någon idé på hur man skulle kunna försvåra detta?

Förresten, någon som vet hur dom där programmen fungerar?


Uträkningar:
255 ^ 7 = 70110209207109375

31536000 sekunder per år

70110209207109375/31536000 = 2223180149,8956549657534246575342

universums ålder ≈ 1,3 10^10 år

Det vanligaste sättet är frekvensanalys. Vissa tecken förekommer betydligt oftare än andra. Substutitionschiffer dör jättesnabbt på det om man vet vilket språk det gäller. Exempel på detta kan läsas i "Order of the Stick".

http://www.giantitp.com/comics/oots0247.html

Det tog inte lång tid för läsarna att dels knäcka chiffret och dels berätta för Rich Burlew att han hade gjort fel.

Vignére försvårar frekvensanalys men som Wikipedia-artikeln säger så finns fortfarande klara trender.

/J

Jag skrev ett program för att knäcka Vigenère-chiffer när jag pluggade, var inte allt för svårt om man ska knäcka filer i skrivna i naturligt språk. Bara att anpassa frekvenstabellen till det språk som filen avser.

Skulle vilja påstå att Vigenere är ett väldigt osäkert krypto.

Byt till en RSA-algoritm istället, mycket svårare att forcera och jäkligt roligt att programmera

Ifall man har en nyckel som är längre än den text man ska kryptera så kan man använda en nästan hur korkad kryptoalgoritm som hellst och ändå få ett i stort sett oknäckbart krypto under förutsättning att du inte använder samma nyckel flera gånger. Engångskrypton bygger på den principen.

Edit: Eftersom jag pluggade elektro så har jag inte läst kursen "kryptografins grunder", men några av mina kompisar har gått den. På den få man lära sig att knäcka i stort sett allt upp till svårighetsgraden Enigma.

Lite rolig litteratur på området är boken
Kodboken av författaren Simon Singh
Efter lite sökande på internet så verkar boken ha utgått på svenska,
men finns kvar på eng. Är på intet sätt en lärobok i krypto men ger
en bra inblick för den oinvigde samt den historiska utvecklingen.
Som helt OT kan jag även rekomendera Fermats Gåta av
samme författare.

/martinator

Hur snabbt man avkrypterar en krypterad fil är iofs intressant men hur snabbt tar man reda på vilken typ av skiffer som är använt?

Okej, du har säkert rätt, RSA är jäkligt bra. Men vad jag vet behöver man använda primtal som är mycket stora, åtminstonde tiotals siffror (gärna hundratals).
Kan du ge mig någon enkel metod för att hitta så stora primtal? Och dessutom förklara så att jag förstår? (Just nu är jag på matte C, vi börjar med derivata imorron)

Att bara ge mig ett, två eller tre primtal skulle inte göra saken bättre, man behöver ganska många primtal för att skapa ett sådant program, eller hur?

Sen var det en till sak, mitt program är gjort så att man har nyckeln i huvudet. Rätta mej om jag har fel, men för RSA-kryptering behöver man dom där stora primtalen jag nyss nämnde när man dekrypterar meddelandet (primtalen är nycklarna, eller iaf nästan som nycklar (jag kan inte allt för mycket om RSA)).
Tidigare sa J-Star att man måste ladda hem .NET framewrork för att programmet ska fungera och att detta var:
Jag undrar om inte det skulle vara ännu värre om programmet sa:
Ange krypteringsnyckel (nyckeln måste bestå av två primtal med minst 20 siffror var, kom ihåg att du inte kan skriva upp dessa siffror eftersom detta skulle minska säkerheten, du måste komma ihåg siffrorna utantill)

Om användaren inte ska ange dessa primtal måste de sparas på datorn och då finns det väl ingen anledning att spara information krypterat på datorn. Gjorde man så skulle man antingen spara primtalen okrypterade (eller dåligt krypterade) eller kanske kryptera dessa primtal med andra primtal, men detta skulle inte fungera eftersom man då skulle behöva dessa primtal med andra primtal som sedan skulle krypteras med andra primmtal och så vidare...

Hur gjorde du förresten?

Edit:

Jo, jag har läst lite i den, dock inte allt för mycket om RSA

Kommer faktiskt inte ihåg i huvudet hur jag gjorde den där uppgiften, var en 8 år sedan på universitetet. Skrev den i C iaf, så mycket kommer jag ihåg. Ska se om jag hittar koden.

Jag håller på med en del förbättringar på programmet, bland annat ett system (brist på bättre ord) som är instpirerat av enigmas slumpkodare ("scramblers" på engelska). En skillnad blir dock att mina "slumpkodare" har 255 olika inställningar till skillnad från enigmas 26 .

Jag ska dock tillägga att det kan ta ett tag innan jag är klar med allt

Tänkte bara tipsa om att läsa in filen binärt istället för att läsa den som strängar.

Hur gör man det, med den där BinaryReader eller? I så fall, hur funkar BinaryReader?


Nu har jag kommit med en uppdatering som har ett antal förbättringar.
Bland annat en ny krypteringsalgoritm som jag kallar "slumpkodare". Dessa fungerar lite som slumpkodarna på Enigma. Nyckeln till dessa är fyra tal, 1-255, som användaren ställer in. Dessa tal sparas i variablerna Räknare1 t.o.m. Räknare4
Vid krypteringsprocessen tar programmet in ett tecken, gör om det till Ascii-tal som sedan skickas till en funktion.
Denna funktion tar in värdet, adderar det med Räknare1 och stoppar in det i en Select Case-sats, som har ett case för varje möjligt värde (1-255), i varje case anges ett outputvärde.
Sedan blir outputvärdet = outputvärdet - Räknare1.

Förhållandet mellan Inputvärdena och Outputvärderna i denna Select Case-sats är helt slumpmässiga, förutom att om input = a blir output = b och om input = b blir output = a.
Med andra ord ger denna funktion ett krypterat output med input i klartext och output i klartext om input är krypterat, förutsatt att Räknare1 har samma värde vid dekryptering som vid kryptering.

Efter denna funktion följer tre andra som fungerar på samma sätt.
En gång för varje tecken ökas Räknare1 med ett, om Räknare1 blir 256, får Räknare1 värdet 1 och Räknare2 ökas med ett och så vidare.

Dessa slumpkodare gör att inget tecken krypteras med samma nyckel, borde inte detta göra det omöjligt att använda frekvensanalys? Jag hoppas ni förstår vad jag menar...


Lite matte:
Antalet möjliga nycklar på slumpkodarna är 255^4 = 4 228 250 625
Ett år (365 dagar) har 31 536 000 sekunder

4 miljarder nycklar är inte så mycket, motsvarar en nyckellängd på ~32 bitar, vilket inte är speciellt mycket. Kryptot knäcks enklast mha bruteforce. Bör gå att knäcka fort. DES som är en helt okej algoritm och har en nyckel på 56 bitar knäcks idag på mindre än 24h.

Här är en bra sida om BinaryReader:
https://webapp.isk.kth.se/falk/jsp/coursewe...e_handling.html

Visserligen för C#, men jag tror att du förstår. Annars finns det säkert i Class Libraryt på MSDN.

Då är det väl bara att öka antalet tecken i nyckeln, det kan jag göra lätt. Funderar på att ta bort viregé-algoritmen (hur man nu stavar till det) och bara använder slumpkodarna.
Hur många möjliga nycklar är nödvändigt?

Förresten, gör dom där slumpkodarna det omöjligt/mkt svårt att använda frekvensanalys?
Eller går det att på något sätt att ta sig runt det?

Det finns gott om krypteringsalgortimer implementeringar av dessa på nätet. Testa någon av de moderna.

/J

Låt oss anta att vi har en nyckel på 10 tecken:
255^10 = 1 162 523 670 191 533 212 890 625
Antalet sekunder på ett år (365 dagar) = 31 536 000

255^10 / 31 536 000 ≈ 3,6 * 10^16

Om man testar en miljon nycklar i sekunden skulle det ta 36 miljarder år innan man blir klar, hade solen med största sannolikhet redan brunnit ut.
Även om det finns snabbare datorer skulle jag säkert vara död innan man hade knäckt kryptot om man använde "brute force".

Frågan är ju nu om det finns något annat sätt att forcera ett sådant krypto?
Vi antar att den som ska forcera kryptot har tillgång till programmets källkod men inte vet något om nyckeln eller klartexten.

Det verkar som det finns folk på det här forumet som vet mer om kryptering än vad jag gör...

Står en del matnyttigt här...
http://en.wikipedia.org/wiki/Brute_force_attack
Glöm inte pararellisering dvs multiprocessor..

Snart släpper AMD 4kärnors processorer...
Och på ett tag så kanske grafikkorten går att använda till beräkningar..

Och det är bara hårdvaran, sen har du en mindre armé av smarta personer som älskar
att hitta säkerhetsmissar..

Lycka till

Det är mycket möjligt att man kan knäcka ett krypto med 255^10 olika nycklar, om man har så stora och dyra datorer. Men, dom som skulle kunna ha nytta av mitt program kommer inte ha några fiender med så stora datorer. Alltså är krypter med ännu fler tecken att betrakta som onödigt, kom ihåg att mitt program inte ska konkurrera med kommersiella krypton, än mindre militära...

Frågan som jag nu ställer mej är om någon skulle hitta en relativt enkel metod (som mycket väl skulle kunna behöva en hel del datorkraft, men inte lika som mycket som behövs för Brute force-atacker) som skulle knäcka kryptot (det med slumpkodarna).
Jag har läst om hur enigma knäcktes och jag får intrycket att man knäckte enigma, dels m.h.a. mycket hårt arbete, men också genoma att utnytja alla fel som tyskarna begick när dom skickade sina meddelanden. Vissa fraser upprepades ofta (t ex "Hei Hitler") och många gånger användes dåligt valda nycklar (t ex "BMW"), kodknäckarna kunde ibland gissa sig till delar av meddelandet och så vidare.

De förändringar (förbättringar enligt mej), som exempelvis att öka antalet slumpkodare som används vid kryptering från 3 till 10 och ökningen av antalet möjliga inställningar av varje slumpkodare fårn 26 till 255, borde väl göra kryptot ganska svårt att forcera.

Vad tror ni?

Läs om Enigma här.

Jag kom på en till fråga: Någon som vet ungefär hur många nycklar man kan testa med brute force? Hur många med en vanlig PC? Med en "vanlig" superdator? Men en väldigt snabb superdator?
Någon som har någon ungefärlig uppfattning?


Tack för länken förresten

Nu har jag blivit klar med en ny version av programmet gå in min hemsida och klicka på Mina program, skrolla ner lite grann och klicka på CryptoCow 4.0.

Nu hoppas jag verkligen att den här tråden är bortglömd, det har ju trots allt tagit lite tid att bli klar med den här versionen.

Hoppas att ni hade en god jul och ett gått nytt år!

Det går redan idag. Faktum är att grafikkortsprocessorer är mycket lämpade för kryptoknäckning, bland annat eftersom de är snabba på och har specialiserade instruktioner för matris- och vektoroperationer.


Det finns säkert. Normalt hittar man sådana metoder genom att studera algoritmen matematiskt. På Wikipedia finns en del information om olika kryptometoder och sätt att forcera dem.

Jovisst är det så. För att till viss del skydda sig mot den typen av kryptoforcering kan man se till att börja och sluta meddelandet med en text som inte har något med meddelandet att göra och som är mer eller mindre slumpmässigt vald.

Det beror helt på vilken typ av algoritm som har använts. Vissa algoritmer är ju konstruerade för att vara så snabba som möjligt medan andra är konstruerade för att vara så långsamma som möjligt (inom vissa gränser förstås). De snabba används lämpligtvis när stora datamängder ska överföras snabbt, medan de långsamma lämpligvis används annars eftersom det med de långsamma tar mycket längre tid att testa alla nycklar. Skillnaden kan vara så stor som en faktor 100 eller mer. Vet man rätt nyckel och ska dekryptera ett meddelande märks den hastighetsskillnaden inte på en modern dator, men ska man testa flera miljarder nycklar kommer den garanterat att märkas. (Ett exempel på detta är OpenBSD som har valt en extremt långsam krypteringsalgoritm till sin lösenordsfil.)

/mdn

Jag kanske ska tillägga att funktionen att kryptera filer som inte skapats av programmet (bilder filmer worddukument osv) fungerar helt och hållet som den ska.
Jag tänkte först använda funktionen BinaryReader för att läsa in filen, men den där BinaryReader förstog jag mej inte på. Men, av en händelse hittade jag funktionen File som bara "råkade" ha en metod som hette ReadAllBytes, det fungerar utmärkt.

Jag har också en ny krypteringsalgoritm som fungerar lite som Enigmas slumpkodare med vissa skillnader:

* Den har 10 slumpkodare, de flersta Enigma-maskiner hade 3
* Varje enskilld slumpkodare kan ha 255 olika inställningar, Enigmas slumpkodare kunde ha 26 olika inställningar
* Dess slumpkodare kan inte flyttas runt
* Den har inga andra saker som krypterar, Enigma hade lite andra grejer

Om ni tittar på de två översta punkterna ser ni att antalet möjliga nycklar är 255^10 = 1 162 523 670 191 533 212 890 625
Om man testade en miljon nycklar skulle det ta ca 36,8 miljarder år att testa alla nycklar (universum beräknas vara 13,7 miljarder år gammalt).
Jag anser därför att min kypteringsalgoritm klarar s.k. brute forrce-attacker tillräckligt bra.

Frågan är nu, finns det något annat sätt att knäcka mitt krypto?