Kryptering i python, är jag säker?

Det du har är en simpel stream cipher med de sårbarheter som är vanliga i stream ciphers.

import random funktionerna i python är inte kryptografisk säkra. random.sample använder ej en cryptographically secure pseudorandom number generator (CSPRNG). Låt oss säga att en attacker kan gissa att meddelandet börjar med "Hej på er alla". Attackern kan då beräkna vissa av värdena i cipher_list som genererades mha random.sample. Med de värdena skulle det kunna vara möjligt att köra random.sample algoritmen baklänges och få reda på vilket värde som användes som seed. Med seed värdet går det beräkna alla värden i cipher_list och dekryptera hela meddelandet. En CSPRNG algoritm är designad så att det är omöjligt att köra beräkningen baklänges och få reda på mer output än vad attackern redan har. Att gissa delar av ett krypterat meddelande är i praktiken ganska enkelt för de flesta krypterade meddelanden följer något protokoll (handshake) som är standardiserat.

Ett annat potentiellt problem är hur mycket entropi random.seed använder. Om du använder en lång krånglig nyckel på 512-bit men random.seed bara har ett internt state på 32-bit är algoritmen ändå trivial att bruteforcea. Jag vet inte hur mycket state pythons seed har men eftersom den inte är till för kryptografi skulle jag inte bli förvånad om det är 32-bit. Som exempel tar C funktionen srand() en unsigned int som vanligtvis bara är 32-bit.

Ett annat problem med stream ciphers är att man aldrig kan använda samma nyckel flera gånger. Låt oss säga att vi krypterar två meddelande med samma nyckel K. Plaintext är P1 och P2 och ciphertext C1 och C2.
kryptering:
P1 + K = C1
P2 + K = C2
avkryptering:
C1 - K = (P1 + K) - K = P1
C2 - K = (P2 + K) - K = P2
En attacker har tillgång till både C1 och C2.
C1 - C2 = (P1 + K) - (P2 + K) = P1 - P2
Attackern kan alltså strippa av K och få ut P1 - P2. Det är inte plaintext men det går ofta gissa vad plaintext är. Många protokoll har null bytes och om P2 är 0 får man direkt ut P1. Här är ett bildexempel som visar saken bättre https://i.imgur.com/PKYvfrX.jpg
Anledningen till att jag tar upp återanvändning av nycklar är att om seed bara är 32-bit så finns det som max bara 2^32 = 4294967296 interna state i PRNGn och cipher_list kommer börja upprepa sig efter det. Med korta meddelanden är det ingen problem men krypterar man några gig så upprepas värdena i cipher_list och det är enkelt att knäcka kryptot.

Dessa problem är generella för stream cipher men din implementation är lite annorlunda eftersom du använder plus och minus i stället för xor vilket är vanligare. Xor används oftare eftersom man inte behöver oroa sig för carry om additionen är för stor och med xor är kryptering och avkryptering samma algoritm eftersom a xor b = c, c xor b = a.

Var fick du siffran 500 i range(500) ifrån? chr() och ord() arbetar med unicode med värden i range 0..1114111 (ca 20-bit) men du adderar bara med värden i range 0..500 (knappt 9-bit). Det försvagar krypteringen enormt. Låt oss säga att en ciphertext har tecknet "俴". ord("俴") = 20468 så vi vet att det motsvarande plaintext tecknet har ett unicode värde i spannet 19968..20468. I det spannet finns 501 kinesiska/japanska tecken så man kan vara säker på att meddelandet inte är på svenska. Du måste se till så att alla tecken i spannet som chr() / ord() arbetar med förekommer i ciphertexten med lika stor sannolikhet. Även om du bara använder standard ascii tecken i meddelandet så försvagas ändå krypteringen av att du använder range(500). Standard ascii är 7-bit (0..127) så ciphertexten borde då har värden i spannet 0..127 i lika stor sannolikhet. Normalt vis arbetar kryptografiska algoritmer på bytes, inte characters eftersom det är enklare.

Min pyton-fu är vek så det finns troligen många andra problem jag inte ser direkt.

@MrMacho: Just vid kryptering, använd alltid något som är beprövat. Nu vet jag inte hur väl beprövat just pycrypto är, men där används vanliga krypteringsalgoritmer som AES och RSA.

Slänger in en generell notis gällande listomfattningar (som jag alldeles nyss bestämde var en bra svensk översättning av "list comprehensions" ): när man i Python ser kodbitar som initierar en tom vektor och sedan fyller på den elementvis så kan man nästan garanterat ersätta det med en listomfattning, och bli gladare på kuppen (garanterat!). Det ger mindre kod som tydligare beskriver intentionen.

Exempelvis kan kodbiten:
mer Pythonskt skrivas som:

    text_as_number = [ord(letter) for letter in txt]

vilket visar poängen med konstruktionen.

På samma sätt så ser vi att du senare använder en listomfattning att skapa en temporär lista att iterera över för att sedan fylla på en tomt initierad vektor:
där du skulle kunna hoppa över ett steg och skriva:

    text_cipher = [chr(a + b) for a, b in zip(text_as_number, cipher_list)]

Här ser vi också att enda användningen för text_as_number är att iterera över den en gång, varpå vi snarare borde valt ett generatoruttryck till att börja med. På samma sätt ser vi att cipher_list också bara används för att låta strängens join-metod iterera över den en gång, så med detta i åtanke kan funktionen i sin helhet skrivas:

def cipher(txt, key):
    text_as_number = (ord(letter) for letter in txt)
    random.seed(key)
    cipher_list = random.sample(range(500), len(txt))
    text_cipher = (chr(a + b) for a, b in zip(text_as_number, cipher_list))
    return ''.join(text_cipher)

Skulle du av någon anledning behöva mata in stora datamängder (men man kan notera att du i nuvarande form får ett ValueError-undantag för strängar längre än 500 tecken) så kommer detta både gå fortare och spara minne, men prestanda är en sidonotis: framför allt så uttrycker det vad du försöker göra mer koncist.

En allmän utflykt om läsbarhet och prestanda: det förstnämnda ska i första hand premieras före prestanda (förrän man vet att det behövs), men vad som är mest "läsbart" bygger ofta (inte alltid) på vad som också är bäst i prestandasynpunkt, eftersom dessa lösningar har en förmåga att bli praxis. En vettig definition på "läsbar kod" är kod som inte ska överraska någon som är van vid språket i fråga. Eftersom någon som är van vid Python bör ha listomfattningar och generatoruttryck i ryggmärgen så är de att föredra framför den mindre koncisa och mer resurskrävande metoden med att lägga till element för element i en loop. Någon som är van vid Python och ser en initialisering av en tom lista tänker automatiskt: "ojdå, här händer nog något märkligt snart eftersom kodaren valde denna metod" vilket gör koden tyngre att läsa (speciellt när det visar sig att inget vidare märkligt händer).

Mycket snack om en liten detalj, kan tyckas, men den är inte så liten som den ser ut, och dessutom ansamlas små detaljer lätt till större härken av svårtydd kod.

När vill man inte skriva listomfattningar? Oftast när elementoperationen är mer komplex än att den går att uttrycka i ett eller ett par korta funktionsanrop, men i mina ögon bör man då definiera en separat funktion som beskriver denna elementoperation och likväl ha tilldelningen som en listomfattning eller ett generatoruttryck. Om operationen är komplex nog för att inte gå att sammanfatta enkelt så bör den lyftas ut.

Ett annat alternativ som kan kännas mer bekant för någon som kommer från andra språk är map, vilket skulle användas som:

    text_as_number = map(ord, txt)

Att hävda att det relativt sett är "ovanligt" att se detta i Python är måhända ett starkt ställningstagande, men jag ställer mig på Alex Martellis axlar och hävdar detta likväl. Listomfattningar mer flexibla och vanligare, och därmed enligt någon definition mer "läsbara".

Det är ofta bra att med tydliga variabelnamn skriva koden så att den "förklarar sig själv", vilket nuvarande kod gör bättre, men känns saker väldigt självklara så skulle man kunna överväga en variant som:

def cipher(txt, key):
    random.seed(key)
    cipher_list = random.sample(range(500), len(txt))
    text_cipher = (chr(ord(a) + b) for a, b in zip(txt, cipher_list))
    return ''.join(text_cipher)

eller kanske till och med bara:

def cipher(txt, key):
    random.seed(key)
    cipher_list = random.sample(range(500), len(txt))
    return ''.join(chr(ord(a) + b) for a, b in zip(txt, cipher_list))

Att baka in även cipher_list-konstruktionen direkt i listomfattningen vore nog att gå väl långt, men kort kod kan vara bra så länge som den fortsätter vara uttrycksfull.

Vill man gå mer överbord så kan man känna hur det kliar i DRY-nerven när det enda som skiljer decrypt och cipher (som väl borde heta encrypt) åt är ett enstaka operatoranrop och titta på förslagsvis operator och functools.partial för att lösa detta.

vill du kryptera text är det bara använda gpg. Där kan du spara varje lösenord som en textfil för att sedan bara kryptera det med gpg. Det du skulle kunna göra är sedan att hålla reda på och sortera dessa för användaren. Dock finns det redan projekt på detta
http://www.passwordstore.org/