it-swarm-eu.dev

Poučení a mylné představy o šifrování a kryptologii

Kryptologie je tak širokým tématem, že i zkušení kodéry budou téměř vždy dělat chyby první několikrát. Šifrování je však tak důležité téma, často si nemůžeme dovolit mít tyto chyby.

Účelem této otázky je identifikovat a uvést, co ne co dělat s daným algoritmem nebo API. Tímto způsobem se můžeme poučit ze zkušeností ostatních a zabránit šíření špatných praktik.

Aby byla tato otázka konstruktivní, prosím

  1. Uveďte „špatný“ příklad
  2. Vysvětlete, co je s tímto příkladem špatné
  3. Zajistěte správnou implementaci (pokud existuje).
  4. Pokud je to možné, uveďte odkazy týkající se # 2 a # 3 výše.
68

Nepoužívejte svůj vlastní krypto.

Nevyvíjejte svůj vlastní šifrovací algoritmus nebo protokol; to je extrémně náchylné k chybám. Jak Bruce Schneier rád říká,

„Kdokoli může vymyslet šifrovací algoritmus, který sám nemůže zlomit; je mnohem těžší vymyslet ten, který nikdo jiný nedokáže zlomit“.

Kryptografické algoritmy jsou velmi složité a vyžadují si důkladné prověření, aby se ujistily, že jsou bezpečné; pokud vymyslíte svůj vlastní, nebudete to mít a je velmi snadné skončit s něčím nejistým, aniž by si to uvědomili.

Místo toho použijte standardní kryptografický algoritmus a protokol. Je pravděpodobné, že se s vaším problémem setkal někdo jiný a pro tento účel navrhl vhodný algoritmus.

Nejlepším případem je použití vysoce prověřeného schématu na vysoké úrovni: pro zabezpečení komunikace použijte TLS (nebo SSL); pro data v klidu použijte GPG (nebo PGP). Pokud to nemůžete udělat, použijte kryptografii na vysoké úrovni, například cryptlib , GPGME, Keyczar nebo NaCL , namísto low-level one, jako OpenSSL, CryptoAPI, JCE, atd .. Díky Nate Lawson za tento návrh.

76
D.W.

Nepoužívejte šifrování bez ověření zprávy

Šifrování dat je velmi častou chybou, aniž by byla také ověřena.

Příklad: Vývojář chce udržovat zprávu v tajnosti, takže šifruje zprávu v režimu AES-CBC. Chyba: To nestačí pro zabezpečení v případě aktivních útoků, opakovaných útoků, reakčních útoků atd. Známé útoky na šifrování bez ověřování zpráv a útoky mohou být docela závažné. Oprava je přidat ověření zprávy.

Tato chyba vedla k vážným zranitelnostem v nasazených systémech, které používaly šifrování bez ověřování, včetně ASP.NET , XML šifrování , Amazon EC2 , JavaServer Faces, Ruby na Rails, OWASP ESAPI , IPSEC , WEP , znovu ASP.NET a SSH2 Nechcete být další v tomto seznamu.

Chcete-li se těmto problémům vyhnout, je nutné použít ověřování zpráv při každém použití šifrování. Jak na to, máte dvě možnosti:

  • Pravděpodobně nejjednodušším řešením je použití schématu šifrování, které poskytuje ověřené šifrování , např. GCM, CWC, EAX, CCM, OCB. (Viz také: 1 .) Ověřené schéma šifrování to zvládne za vás, takže o tom nemusíte přemýšlet.

  • Alternativně můžete použít vlastní ověřování zpráv následujícím způsobem. Nejprve zašifrujte zprávu pomocí vhodného schématu šifrování symetrických klíčů (např. AES-CBC). Poté vezměte celý šifrový text (včetně všech IV, nonces nebo jiných hodnot potřebných pro dešifrování), použijte ověřovací kód zprávy (např. AES-CMAC, SHA1-HMAC, SHA256-HMAC) a připojte výsledný výtah MAC k ciphertext před přenosem. Na přijímací straně před dešifrováním zkontrolujte, zda je digest MAC platný. Toto se nazývá konstrukce šifrování a autentizace. (Viz také: 1 , 2 .) To také funguje dobře, ale vyžaduje od vás trochu větší péče.

47
D.W.

Při zřetězování více řetězců před hašováním buďte opatrní

Někdy vidím chybu: Lidé chtějí hash řetězců S a T. Zřetězí je tak, aby dostali jeden řetězec S || T, potom hash pro získání H (S || T). To je vadné.

Problém: Zřetězení ponechává hranici mezi dvěma řetězci dvojznačnou. Příklad: builtin || securely = built || insecurely. Jinak řečeno, hash H (S || T) jednoznačně neidentifikuje řetězce S a T. Útočník tedy může být schopen změnit hranici mezi dvěma řetězci, aniž by změnil hash. Pokud například Alice chtěla poslat dva řetězce builtin a securely, útočník by je mohl změnit na dva řetězce built a insecurely bez zneplatnění hash.

Podobné problémy se vyskytují při použití digitálního podpisu nebo ověřovacího kódu zprávy na zřetězení řetězců.

Oprava: místo pouhého zřetězení použijte nějaké kódování, které je jednoznačně dekódovatelné. Například namísto výpočtu H (S || T) můžete vypočítat H (délka (S) || S || T), kde délka (S) je 32bitová hodnota označující délku S v bajtech. Nebo je další možností použití H (H (S) || H (T)) nebo dokonce H (H (S) || T).

Příklad této chyby v reálném světě viz tato chyba v Amazon Web Services nebo tato chyba v Flickr [pdf].

36
D.W.

Nepoužívejte nonces nebo IVs

Mnoho způsobů provozu vyžaduje IV (inicializační vektor). Nikdy nesmíte znovu použít stejnou hodnotu pro IV. může to zrušit všechny bezpečnostní záruky a způsobit katastrofické porušení bezpečnosti.

  • Pro provozní režimy šifrování proudu, jako je režim CTR nebo OFB, je opětovné použití jednotky IV bezpečnostní katastrofou. To může způsobit, že zašifrované zprávy budou triviálně obnovitelné.

  • Pro jiné provozní režimy, jako je režim CBC, může opětovné použití IV v některých případech také usnadnit útoky na obnovu prostého textu.

Bez ohledu na to, jaký režim provozu používáte, neměli byste znovu použít IV. Pokud vás zajímá, jak to udělat správně, specifikace NIST poskytuje podrobnou dokumentaci o tom, jak správně používat režimy blokové šifry.

Projekt Tarsnap je dobrým příkladem tohoto úskalí. Tarsnap šifruje záložní data tak, že je rozdělí na kousky a poté šifruje každý kus pomocí AES v režimu CTR. Ve verzích 1.0.22 až 1.0.27 Tarsnap byl stejný IV neúmyslně znovu použit, což umožnilo zotavení prostého textu.

Jak se to stalo? Za účelem zjednodušení kódu Tarsnap - a v naději, že se sníží potenciál chyb - využil Colin Percival příležitost „refaktorovat“ kód AES-CTR do nového souboru (lib/crypto/crypto_aesctr.c ve zdrojovém kódu Tarsnap). ) a upravila existující místa, kde byla AES-CTR využita k využití těchto rutin. Nový kód vypadá takto:

/* Zašifrujte data. */
 - aes_ctr (& encr_aes-> key, encr_aes-> nonce ++, buf, len, 
 - filebuf + CRYPTO_FILE_HLEN); 
 + if ((stream = [.____.). ] + crypto_aesctr_init (& encr_aes-> key, encr_aes-> nonce)) == NULL) 
 + goto err0; 
 + crypto_aesctr_stream (stream, buf, filebuf + CRYPTO_FILE_HLEN, len); 
 + crypto_aesctr_free (stream); 

Během refactoring, encr_aes->nonce++ neúmyslně se změnilo na encr_aes->nonce, a jako výsledek byla opakovaně použita stejná hodnota nonce . Zejména hodnota nonce CTR se nezvýší po zašifrování každého bloku. (Čítač CTR je správně zvýšen po zpracování všech 16 bajtů dat, ale tento čítač je resetován na nulu pro každý nový blok.) Úplné podrobnosti jsou popsány Colinem Percivalem v: http: //www.daemonologie. net/blog/2011-01-18-tarsnap-critical-security-bug.html

29
Alex Holst

Ujistěte se, že jste nasadili generátory náhodných čísel s dostatečnou entropií.

Ujistěte se, že používáte generátory pseudonáhodných čísel s kryptografickým číslem pro věci jako generování klíčů, výběr IV/nonces atd. Nepoužívejte Rand(), random(), drand48() , atd.

Ujistěte se, že generátor pseudonáhodných čísel nasadí dostatečnou entropii. Nenasévejte to s denní dobou; to je hádatelné.

Příklady: srand(time(NULL)) je velmi špatné. Dobrým způsobem, jak vložit vaše PRNG), je chytit 128 bitů nebo pravdivých náhodných čísel, například z /dev/urandom, CryptGenRandom nebo podobné. V Javě použijte SecureRandom, nikoli Random. V prostředí .NET použijte System.Security.Cryptography.RandomNumberGenerator, nikoli System.Random. V Pythonu použijte náhodné.SystemRandom, nikoli náhodné. Díky Nate Lawson za několik příkladů.

Příklad ze skutečného světa: viz tato chyba v dřívějších verzích prohlížeče Netscape , která útočníkovi umožnila rozbít SSL.

29
D.W.

Nepoužívejte blokovou šifru s ECB pro symetrické šifrování

(Platí pro AES, 3DES, ...)

Zde je post a velmi podobný článek Microsoft KB týkající se toho, jak režim ECB vede k kódu, který není šifrován.

Viz také tento podobný příspěvek z Rook

Obyčejná textová zpráva:

alt text

Stejná zpráva šifrovaná v režimu ECB (nezáleží na tom, jakou šifru používáte): alt text

EXACT stejná zpráva v režimu CBC (opět nezáleží na tom, jakou šifru používáte): alt text

Špatná cesta

public static string Encrypt(string toEncrypt, string key, bool useHashing)
{

byte[] keyArray = UTF8Encoding.UTF8.GetBytes(key);
byte[] toEncryptArray = UTF8Encoding.UTF8.GetBytes(toEncrypt);

if (useHashing)
    keyArray = new MD5CryptoServiceProvider().ComputeHash(keyArray);

var tdes = new TripleDESCryptoServiceProvider() 
    { Key = keyArray, Mode = CipherMode.ECB, Padding = PaddingMode.PKCS7 };

ICryptoTransform cTransform = tdes.CreateEncryptor();
byte[] resultArray = cTransform.TransformFinalBlock(
    toEncryptArray, 0, toEncryptArray.Length);

return Convert.ToBase64String(resultArray, 0, resultArray.Length);
}

Chyba je na následujícím řádku

{Key = keyArray, Mode = CipherMode.ECB , Padding = PaddingMode.PKCS7};


Správná cesta

Dobří lidé z Microsoftu mi poslali následující kód k opravě výše uvedeného článku KB. To je uvedeno v případě # 111021973179005

Tento ukázkový kód používá AES k šifrování dat a klíčem pro šifrování AES je hashovací kód vygenerovaný SHA256. AES je algoritmus AES (Advanced Encryption Standard). Algoritmus AES je založen na permutacích a substitucích. Permutace jsou přeskupení dat a substituce nahrazují jednu jednotku dat jinou. AES provádí permutace a substituce pomocí několika různých technik. Další podrobnosti o AES naleznete v článku „Zachovejte svá data v bezpečí pomocí nového standardu pro pokročilé šifrování“ na webu MSDN Magazine na adrese http://msdn.Microsoft.com/en-us/magazine/cc164055.aspx .

SHA je algoritmus Secure Hash. Nyní se doporučuje SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512). Podrobnější informace o hodnotách hash v rozhraní .NET Framework naleznete na http://msdn.Microsoft.com/en-us/library/92f9ye3s.aspx#hash_values .

Výchozí hodnota režimu pro provoz symetrického algoritmu pro AesCryptoServiceProvider je CBC. CBC je režim kódování blokových bloků. Zavádí zpětnou vazbu. Před zakódováním každého bloku prostého textu je tento kombinován s šifrovým textem předchozího bloku bitově exkluzivní operací OR). Tím je zajištěno, že i když prostý text obsahuje mnoho identických bloků, budou každý zašifruje do jiného šifrového textového bloku. Inicializační vektor je kombinován s prvním prostým textovým blokem bitově exkluzivní operací OR) před šifrováním bloku. Je-li jeden bit textového bloku šifry je upraven, odpovídající blok prostého textu bude rovněž upraven. Kromě toho bude upraven bit v následném bloku, na stejné pozici jako původní upravený bit. Podrobnější informace o CipherMode získáte viz http://msdn.Microsoft.com/en-us/library/system.security.cryptography.ciphermode.aspx .

Zde je ukázkový kód.

// This function is used for encrypting the data with key and iv.
byte[] Encrypt(byte[] data, byte[] key, byte[] iv)
{
    // Create an AESCryptoProvider.
    using (var aesCryptoProvider = new AesCryptoServiceProvider())
    {
        // Initialize the AESCryptoProvider with key and iv.
        aesCryptoProvider.KeySize = key.Length * 8;
        aesCryptoProvider.IV = iv;
        aesCryptoProvider.Key = key;

        // Create encryptor from the AESCryptoProvider.
        using (ICryptoTransform encryptor = aesCryptoProvider.CreateEncryptor())
        {
            // Create memory stream to store the encrypted data.
            using (MemoryStream stream = new MemoryStream())
            {
                // Create a CryptoStream to encrypt the data.
                using (CryptoStream cryptoStream = new CryptoStream(stream, encryptor, CryptoStreamMode.Write))
                    // Encrypt the data.
                    cryptoStream.Write(data, 0, data.Length);

                // return the encrypted data.
                return stream.ToArray();
            }
        }
    }
}

// This function is used for decrypting the data with key and iv.
byte[] Decrypt(byte[] data, byte[] key, byte[] iv)
{
    // Create an AESCryptoServiceProvider.
    using (var aesCryptoProvider = new AesCryptoServiceProvider())
    {
        // Initialize the AESCryptoServiceProvier with key and iv.
        aesCryptoProvider.KeySize = key.Length * 8;
        aesCryptoProvider.IV = iv;
        aesCryptoProvider.Key = key;

        // Create decryptor from the AESCryptoServiceProvider.
        using (ICryptoTransform decryptor = aesCryptoProvider.CreateDecryptor())
        {
            // Create a memory stream including the encrypted data.
            using (MemoryStream stream = new MemoryStream(data))
            {
                // Create a CryptoStream to decrypt the encrypted data.
                using (CryptoStream cryptoStream = new CryptoStream(stream, decryptor, CryptoStreamMode.Read))
                {
                    // Create a byte buffer array.
                    byte[] readData = new byte[1024];
                    int readDataCount = 0;

                    // Create a memory stream to store the decrypted data.
                    using (MemoryStream resultStream = new MemoryStream())
                    {
                        do
                        {
                            // Decrypt the data and write the data into readData buffer array.
                           readDataCount = cryptoStream.Read(readData, 0, readData.Length);
                            // Write the decrypted data to resultStream.
                            resultStream.Write(readData, 0, readDataCount);
                        }
                        // Check whether there is any more encrypted data in stream.
                        while (readDataCount > 0);
                        // Return the decrypted data.
                        return resultStream.ToArray();
                    }
                }
            }
        }
    }
}



// This function is used for generating a valid key binary with UTF8 encoding and SHA256 hash algorithm.
byte[] GetKey(string key)
{
    // Create SHA256 hash algorithm class.
    using (SHA256Managed sha256 = new SHA256Managed())

    // Decode the string key to binary and compute the hash binary of the key.
    return sha256.ComputeHash(Encoding.UTF8.GetBytes(key));
}

Další podrobnosti o třídách v ukázkovém kódu naleznete na následujících odkazech:

· AesCryptoServiceProvider Class

· SHA256Managed Class

· třída CryptoStream

Kromě toho existuje několik článků, které mohou pomoci lépe porozumět kryptografii v rozhraní .NET Framework, viz níže uvedené odkazy:

· kryptografické služby

· . NET Framework Cryptography Model

· Jednoduchý průvodce kryptografií

· Šifrování bez tajemství

20

Nepoužívejte stejný klíč pro šifrování i ověřování. Nepoužívejte stejný klíč pro šifrování i podepisování.

Klíč by neměl být znovu použit pro více účelů; které mohou otevřít různé jemné útoky.

Například, pokud máte pár soukromých/veřejných klíčů RSA, neměli byste jej používat jak pro šifrování (šifrování pomocí veřejného klíče, dešifrování pomocí soukromého klíče), tak pro podepisování (podepisování soukromým klíčem, ověření veřejným klíčem). ): vyberte jeden účel a použijte jej pouze k jednomu účelu. Pokud potřebujete obě schopnosti, vygenerujte dva klíče, jeden pro podepisování a druhý pro šifrování/dešifrování.

Podobně u symetrické kryptografie byste měli použít jeden klíč pro šifrování a samostatný nezávislý klíč pro autentizaci zpráv. Nepoužívejte stejný klíč pro oba účely.

20
D.W.

Kerckhoffův princip: Kryptosystém by měl být bezpečný, i když vše o systému, s výjimkou klíče, je veřejná znalost

Špatný příklad: hash LANMAN

LANMAN hashe by bylo těžké přijít na to, kdyby nikdo neznal algoritmus, ale jakmile byl algoritmus znám, je nyní velmi triviální praskat.

Algoritmus je následující ( z wikipedia ):

  1. Uživatelské heslo ASCII heslo je převedeno na velká písmena).
  2. Toto heslo je vyplněno na 14 bajtů
  3. Heslo s pevnou délkou je rozděleno na dvě poloviny sedm bajtů.
  4. Tyto hodnoty se používají k vytvoření dvou klíčů DES, jeden z každé 7bajtové poloviny)
  5. Každý ze dvou klíčů se používá k DES-šifrování konstanty ASCII řetězec „KGS! @ # $%“), Což má za následek dvě hodnoty 8 bajtů ciphertext.
  6. Tyto dvě hodnoty šifrového textu jsou zřetězeny tak, aby tvořily 16bajtovou hodnotu, což je hash LM

Protože nyní znáte ciphertext těchto skutečností, můžete nyní velmi snadno rozdělit ciphertext na dva ciphertext, což je velká písmena, což vede k omezené sadě znaků, kterými by mohlo být heslo.

Správný příklad: šifrování AES

  • Známý algoritmus
  • Váhy s technologií. Pokud potřebujete více kryptografických znaků, zvyšte velikost klíče
17
Chris Dale

Zkuste se vyhnout použití hesel jako šifrovacích klíčů.

Častou slabinou v mnoha systémech je použití hesla nebo přístupové fráze nebo hash hesla nebo přístupové fráze jako šifrovacího/dešifrovacího klíče. Problém je v tom, že to bývá vysoce citlivé na offline útoky na vyhledávání klíčů. Většina uživatelů si vybírá hesla, která nemají dostatečnou entropii, aby těmto útokům odolávala.

Nejlepší oprava je použití skutečně náhodného šifrovacího/dešifrovacího klíče, nikoliv deterministicky vygenerovaného z hesla/přístupové fráze.

Pokud však musíte použít heslo založené na hesle/přístupové frázi, použijte vhodné schéma ke zpomalení vyčerpávajícího vyhledávání klíčů. Doporučuji PBKDF2 , který používá iterativní hašování (podél řádků H(H(H(....H(password)...)))) Zpomalit hledání slovníku. Uspořádat použití dostatečného množství iterací, aby tento proces zabral, řekněme, 100ms na stroji uživatele, aby vygeneroval klíč.

13
D.W.

V kryptografickém protokolu: možněte rozeznání každé ověřené zprávy: žádné dvě zprávy by neměly vypadat stejně

Generalizace/varianta:

  • Při hašení více řetězců před hašováním buďte opatrní.
  • Nepoužívejte klíče znovu.
  • Nepoužívejte nonces.

Během běhu kryptografického protokolu lze vyměnit mnoho zpráv, které nelze falšovat bez tajného (klíče nebo jiného). Tyto zprávy mohou být přijaty ověřeny, protože zná nějaký veřejný (podpisový) klíč, nebo protože pouze on a odesílatel zná symetrický klíč nebo jiné. Tím zajistíte, že tyto zprávy nebyly změněny.

Ale to není , ujistěte se, že tyto zprávy byly vysílány během stejného běhu protokolu: protivník mohl tyto zprávy zachytit dříve nebo během souběžné spuštění protokolu. Protivník může spustit mnoho souběžných běhů kryptografického protokolu, aby zachytil platné zprávy a znovu je použil nezměněné.

Chytrým nahrazováním zpráv by mohlo být možné zaútočit na protokol bez ohrožení jakéhokoli primárního klíče, bez napadení jakéhokoli RNG, jakéhokoli cypher atd.

Díky tomu, že každá ověřená zpráva protokolu je pro příjemce zřetelně odlišná, jsou možnosti opakovaného přehrávání neupravených zpráv omezeny (nevyloučeny).

13
curiousguy

Nepoužívejte nezabezpečené délky klíčů.

Ujistěte se, že používáte algoritmy s dostatečně dlouhým klíčem.

Pro kryptografii symetrických klíčů bych doporučil alespoň 80bitový klíč, a pokud je to možné, 128bitový klíč je dobrý nápad. Nepoužívejte 40bitové šifrování; je to nejistá a snadno rozbitá amatéry, jednoduše vyčerpávajícím vyzkoušením všech možných klíčů. Nepoužívejte 56bitové DES; není triviální zlomit, ale je v dosahu odhodlaných útočníků rozbít DES. 128bitový algoritmus, jako je AES, není výrazně pomalejší než 40bitové kryptogramy, takže nemáte žádné omluvy pro použití kryptoměni.

Pro kryptografii veřejného klíče závisí délka klíče na algoritmu a na požadované úrovni zabezpečení. Také zvětšení velikosti klíče poškozuje výkon, takže masivní nadměrné používání není ekonomické; to tedy vyžaduje trochu více přemýšlení než výběr velikosti klíčů se symetrickým klíčem. Pro RSA, El Gamal nebo Diffie-Hellman bych doporučil, aby klíč byl alespoň 1024 bitů, jako absolutní minimum; 1024bitové klíče jsou však na okraji toho, co by se mohlo v dohledné době stát prasknutelným a obvykle se pro moderní použití nedoporučuje, takže pokud je to možné, doporučuji 1536 nebo dokonce 2048bitové klíče. Pro kryptografii eliptické křivky se 160bitové klíče zdají být adekvátní a 224bitové klíče jsou lepší. Můžete také odkázat na publikované pokyny, kterými se stanoví hrubá ekvivalence mezi velikostmi symetrických a veřejných klíčů .

8
D.W.

Nepoužívejte stejný klíč v obou směrech.

V síťové komunikaci je běžnou chybou použít stejný klíč pro komunikaci ve směru A - B jako ve směru B -> A. To je špatný nápad, protože to často umožňuje opakované útoky, které přehrávají něco A zaslané B, zpět na A.

Nejbezpečnějším přístupem je vyjednat dva nezávislé klíče, jeden pro každý směr. Alternativně můžete vyjednat jeden klíč K a poté použít K1 = AES (K, 00..0) pro jeden směr a K2 = AES (K, 11..1) pro druhý směr.

8
D.W.

Jednorázová podložka není jednorázová podložka, pokud je klíč natažen algoritmem

Identifikátor "jednorázová podložka" (také známá jako Vernamova šifra) je často nesprávně aplikována na různá kryptografická řešení ve snaze uplatnit nerozbitné zabezpečení. Ale podle definice je Vernamova šifra bezpečná pouze tehdy, jsou-li splněny všechny tři tyto podmínky:

  • Klíčový materiál je skutečně nepředvídatelný; A
  • Klíčový materiál má stejnou délku jako prostý text; A
  • Klíčový materiál není nikdy znovu použit.

Jakékoli porušení těchto podmínek znamená, že se nejedná o jednorázovou padovou šifru.

Častou chybou je, že krátký klíč je natažen pomocí algoritmu. Tato akce porušuje pravidlo nepředvídatelnosti (nevadí pravidlo délky klíče.) Jakmile je to hotovo, jednorázová klávesnice je matematicky transformována do algoritmu pro natahování klíčů. Kombinace krátké klávesy s náhodnými bajty pouze změní vyhledávací prostor potřebný k brutálnímu vynucení algoritmu natahování klíčů. Podobně použití „náhodně generovaných“ bajtů změní algoritmus generování náhodných čísel na bezpečnostní algoritmus.

Zde je jednoduchý příklad. Mám zprávu, kterou zašifruji pomocí „jednorázové klávesnice“, která používá jako generátor klíčů kryptograficky bezpečnou funkci. Vybral jsem tajný klíč a poté k němu přidal náhodné číslo, aby bylo zajištěno, že nebude znovu použito. Protože klíč znovu nepoužívám, neexistuje způsob, jak zaútočit na šifrový text odečtením jedné zprávy od druhé.

          plaintext : 1234567890123456789012345678901234567890
       key material : 757578fbf23ffa4d748e0800dd7c424a46feb0cc
OTP function (xor)  : ----------
         ciphertext : 67412E83622DCE1B0C1E1A348B04D25872A8C85C

Klíčový materiál byl bezpečně vygenerován pomocí SHA-1, aby bylo možné hashovat moje tajné heslo (plus náhodné), aby se protáhlo. Ale každý útočník, který zná natahovací algoritmus *, který používá, je SHA-1, ale může na něj zaútočit vyzkoušením různých vstupů do SHA-1 a XORing výstupem s ciphertext. Hádání klíče „OTP“ nyní není o nic těžší, než odhadnout kombinované vstupy do kryptografického algoritmu. Tato vlastnost platí bez ohledu na to, který základní kryptografický algoritmus je vybrán, jaká měřítka složitosti drží nebo jak je implementována nebo nasazena.

Možná máte velmi dobrý algoritmus pro roztahování klíčů. Můžete mít také velmi bezpečný generátor náhodných čísel. Váš algoritmus však podle definice není jednorázovou podložkou, a proto nemá nerozbitnou vlastnost jednorázové podložky.

* Uplatnění Kerckhoffova principu znamená, že musíte předpokládat, že útočník dokáže vždy určit použité algoritmy.

3
John Deters

Použijte správný režim

Rovněž se nespoléhejte na zabezpečení výchozího nastavení knihovny. Konkrétně mnoho knihoven, které implementují AES, implementuje algoritmus popsaný v FIPS 197, což je režim tzv. ECB (Electronic Code Book), což je v podstatě přímé mapování:

AES(plaintext [32]byte, key [32]byte) -> ciphertext [32]byte

je velmi nejistá. Důvod je jednoduchý, zatímco počet možných kláves v prostoru kláves je poměrně velký, slabým článkem je však množství entropie ve zprávě. Jako vždy, xkcd.com popisuje, že je lepší než já http://xkcd.com/257/

Je velmi důležité použít něco jako CBC (Cipher Block Chaining), které v podstatě dělá ciphertext [i] mapováním:

ciphertext[i] = SomeFunction(ciphertext[i-1], message[i], key)

Stačí poukázat na několik jazykových knihoven, kde je tento druh chyby snadno proveditelný: http://golang.org/pkg/crypto/aes/ poskytuje implementaci AES, která, pokud bude použita naivně, by výsledek v režimu ECB.

Při vytváření nového objektu AES je knihovna pycrypto nastavena na režim ECB.

OpenSSL, dělá to správně. Každé volání AES je výslovně o režimu provozu. Opravdu nejbezpečnější věc, kterou IMO je, je prostě pokusit se nedělat krypto na nízké úrovni, jako je tento sám. Pokud jste nuceni, pokračujte, jako byste chodili po rozbitém skle (pečlivě), a zkuste se ujistit, že vaši uživatelé jsou oprávněni vložit důvěru ve vás a chránit svá data.

3
Shane Hansen

Nepoužívejte stejný klíč na mnoha zařízeních.

Čím více sdílíte kryptografický klíč, tím je méně pravděpodobné, že ho budete udržovat v tajnosti. Některé nasazené systémy znovu použily stejný symetrický klíč na každém zařízení v systému. Problém je v tom, že dříve nebo později někdo vyjme klíč z jediného zařízení a poté bude moci zaútočit na všechna ostatní zařízení. Takže to nedělejte.

Viz také „Symetrické šifrování Don't # 6: Nesdílejte jediný klíč na mnoha zařízeních“ v tento článek v blog . Úvěry Matthew Green.

3
D.W.

Při šifrování disku nepoužívejte šifrování OTP nebo stream

Příklad 1

Předpokládejme, že dva soubory jsou uloženy pomocí proudové šifry/OTP. Pokud je soubor po menší úpravě obnoven, může útočník vidět, že byly změněny pouze některé bity, a odvodit informace o dokumentu. (Představte si změnu oslovení „Drahý Bob“ na „Drahá Alice“).

Příklad 2

Ve výstupu není žádná integrita: útočník může modifikovat ciphertext a upravit obsah dat jednoduše XORing data.

Odebrat: Úpravy šifrového textu jsou nezjištěné a mají předvídatelný dopad na prostý text.

Řešení

Použijte blokovou šifru pro tyto situace, které zahrnují kontrolu integrity zpráv

1

Don't Trust Standards.

V kryptografii existuje mnoho standardů a někdy je musíte použít. Nepředpokládejte však, že lidé, kteří vytvářejí normy, dostatečně rozuměli kryptografii, kterou potřebovali. Například EAX byl přepracován v síťovém standardu. EAX má důkaz o bezpečnosti. Přepracovaná verze ne.

MD5 je standard. Nyní je rozbité. Čip a PIN byl mnohokrát zlomen, díky množství nebezpečných funkcí. GPG stále podporuje klíče DSA, které jsou příliš krátké pro pohodlí. SSL má možnosti, které by se neměly používat a vyžadují starat se jim vyhnout.

Co s tím lze udělat? Buďte opatrní, pochopte známá rizika a držte krok s výzkumem nových.

1
Watson Ladd

Používejte pouze MAC, které nejsou náchylné k útokům na rozšíření zpráv

MAC je hash kód, který zajišťuje integritu zprávy (žádné úpravy atd.) Daného prostého textu. Mnoho implementací a publikovaných standardů nedokáže chránit MAC před útočníkem, který k MAC přidá další data.

Řešením je, že implementace MAC používá druhý (jiný) klíč a znovu zašifruje konečný výstup.

ECBC a NMAC jsou příklady šifry, které správně zabraňují útoku rozšíření zprávy.

Řešení:

  • Použijte Encrypted CBC (ECBC) místo raw CBC
  • Místo NMAC použijte cascade
0

Nikdy nepoužívejte jednorázový pad (OTP) nebo šifrovací klíč proudu více než jedno

Dvojnásobné použití protokolu OTP znamená, že data zašifrovaná pomocí „dokonalého tajemství“ budou dešifrována a jasně. K tomu dochází, protože data jsou XOR'ed dvakrát.

Příklad

Předpokládejme, že OTP/nebo stream se stejným klíčem se znovu používá.

Útočník shromažďuje velké množství dat odeslaných z klienta na server a XOR společně sestavuje sadu dvou paketů, dokud se oba pakety navzájem nešifrují (nebo v nich nevyjímají).

Kódování ASCII má dostatečnou redundanci, což znamená, že při dostatečném počtu šifrových textů by mohly být původní zprávy dekódovány (spolu s tajným klíčem OTP).

Příklady ze skutečného světa

  • Projekt Verona (1941-46) jako příklad OTP používaného Rusy a byl následně dešifrován zpravodajskou agenturou USA

  • Microsoft PPTPv1 klient i server šifrují data pomocí stejného klíče.

  • WEP znovu použije stejný klíč, jakmile jsou odeslány 2 ^ 24 pakety, nebo pokud je resetována karta NIC karta je resetována). První problém je způsoben tím, že IV je 24 bitů dlouhý, což vede k tomu, že po 16 milionech rámců jsou přenáší se dva časové bloky. Druhý problém se vyskytuje v hardwarových implementacích, kde se po energetickém cyklu IV resetuje na nulu, což má za následek dvojí časové pole.

Doporučení

  • Pro každou relaci (např. TLS) by měl být vytvořen nový klíč.

  • Klient by měl se serverem použít jeden OTP (nebo streamovanou šifru w/PRG) a server by měl použít šifrování jiný klíč při šifrování dat do klienta

  • Spíše než vygenerovat mnoho mnoha klíčů, je možné rozšířit jeden klíč do dlouhého proudu pomocí PRG (za předpokladu, že PRG důvěřujete) a použít každý segment této expanze jako klíč.

  • Uvědomte si, že ne všechny PRG jsou nuceny pracovat v přírůstkovém režimu a může být vyžadován náhodný vstup. (RC4 má tento problém v přírůstkovém režimu)

0

Nepoužívejte RC4

RC4 byl navržen v roce 1987 pro použití jako proudová šifra. Používá se v HTTPS a WEP.

Existují slabiny

  1. V počátečním výstupu je zkreslení: Pr [2. bajt = 0] = 2/256
  2. Pravděpodobnost šestnácti bitů rovných nule je 1/256 ^ 2 + 1/256 ^ 3. K tomu dochází po zašifrování několika koncertů dat.
  3. Zranitelný s příbuznými klíčovými útoky, kde se změní pouze IV, ale klíč zůstane stejný.

Odneste - Pokud musíte použít RC4, ignorujte prvních 256 bajtů, protože jsou zkreslené. Pokud používáte RC4 pro koncerty dat, pak zaujatost v RC4 umožní útoky na všechna předchozí šifrovaná data.

0

Používejte moderní procesory streamů, které pracují vhodně v hardwaru nebo softwaru

Ne všechny proudové šifry jsou navrženy k implementaci do hardwaru nebo softwaru. Lineární zpětnovazební posuvný registr (LFSR) je příklad široce používaného hardwarového šifru, který lze snadno rozbít.

LFSR se používá v:

  • Šifrování DVD (známé také jako CSS) 2 LFSR
  • Šifrování GSM (A5/1.2) 3 LSFR
  • Bluetooth (E0): 4 LFSR

Hardware výše uvedeného je široce nasazen, a proto je obtížné jej aktualizovat nebo přizpůsobit moderním standardům. Všechny výše uvedené skutečnosti jsou velmi poškozené a neměly by být důvěryhodné pro bezpečnou komunikaci.

Útok:

Protože klíč je během šifrování rozdělen na dvě části (17 bitů a 25 bitů) a tyto bity se používají k šifrování stejného textu šifry, je možné využít znalosti formátu MPEG a pomocí 17bitového klíče extrapolovat, jaký klíč má 25bit je.

Toto není sotva nové, ale FOSS lze snadno najít, což ukazuje tento problém.

Řešení:

projekt eStream (v roce 2008) kvalifikoval 5 proudových šifrů, které by měly být použity. Pozoruhodný rozdíl je, že místo použití klíče s IV, šifry používají klíč, nonce a čítač. Salsa20 pracuje tímto způsobem a je navržen pro snadné použití v hardwaru i softwaru. Konkrétně je součástí instrukční sady x86 SSE2.

Kromě

Moderní šifry jsou nejen bezpečnější, ale také rychlejší:

PRG          Speed (MB/sec)
RC4              126         (obsolete)
Salsa20/12       643         (modern)
Sosemaunk        727         (modern)
0