Szyfrowanie AES

Witam. Obecnie męczę się nad stworzeniem funkcji szyfrującej i nawet takową z pomocą internetu udało mi się napisać. Jednakże mam kilka pytań odnośnie:

• IV
• Salt
• Key

Z tego co czytałem pierwsze dwa elementy mają dodać "losowości" do naszego szyfrowania, więc jak należy je generować, żeby później rozszyfrować np. stringa ?
Obecnie robię to w ten sposób, więc zapewne źle, aczkolwiek działa:

RMCrypto.Key = CreateKey(key);
RMCrypto.IV = CreateKey(key);
var encryptor = RMCrypto.CreateEncryptor(RMCrypto.Key, RMCrypto.IV);

private static byte[] CreateKey(string InputKey)
{
    var key = new Rfc2898DeriveBytes(InputKey, saltBytes);
    return key.GetBytes(16);    
}

Kompletnie nie rozumiem idei działania tych dwóch pierwszych "mechanizmów", byłby ktoś na tyle miły, żeby mi to wytłumaczyć ?

Pozdrawiam :)

Pewnie szyfrujesz za pomocą jakiegoś hasła. Zawsze jedno i drugie możesz generować na jego podstawie:

using System;
using System.Text;
using System.Linq;
using System.Security.Cryptography;
using System.IO;

namespace Prg {   
    public class AES {
        public enum Process {
            Encryption,
            Decryptopn
        }

        private AesCryptoServiceProvider _aes;

        public AES() {
            this._aes = new AesCryptoServiceProvider();
            this._aes.KeySize = 256;
            this._aes.BlockSize = 128;
        }

        public byte[] Encrypt(byte[] plain, string password, Process process = Process.Encryption) {
            try {
                using (var pass = new PasswordDeriveBytes(password, this.GenerateSalt(this._aes.BlockSize / 8, password))) {
                    using (var stream = new MemoryStream()) {
                        this._aes.Key = pass.GetBytes(this._aes.KeySize / 8);
                        this._aes.IV = pass.GetBytes(this._aes.BlockSize / 8);

                        var proc = (process == Process.Encryption) ? this._aes.CreateEncryptor() : this._aes.CreateDecryptor();
                        using (var crypto = new CryptoStream(stream, proc, CryptoStreamMode.Write)) {
                            crypto.Write(plain, 0, plain.Length);
                            crypto.Clear();
                            crypto.Close();
                        }
                        stream.Close();
                        return stream.ToArray();
                    }
                }
            }
            catch (Exception ex) {
                Console.WriteLine(ex.ToString());
                return null;
            }
        }

        private byte[] GenerateSalt(int size, string password) {
            var buffer = new byte[size];
            var passBytes = ASCIIEncoding.ASCII.GetBytes(password);

            if (passBytes.Length > buffer.Length) Array.Copy(passBytes, buffer, buffer.Length);
            else Array.Copy(passBytes, buffer, passBytes.Length);

            return buffer;
        }

        public byte[] Decrypt(byte[] encrypted, string password) {
            return this.Encrypt(encrypted, password, Process.Decryptopn);
        }
    }

    class Program {
        public static void Main(string[] args) {
            var aesEncrypt = new AES();
            var plain = "Grzesiek Tomek Kasia";
            var encrypted = aesEncrypt.Encrypt(ASCIIEncoding.ASCII.GetBytes(plain), "haselko");

            // Nowa instancja żeby zasymulować rzeczywiste działanie.
            var aesDecrypt = new AES();
            var decrypted = aesDecrypt.Decrypt(encrypted, "haselko");

            Console.WriteLine(ASCIIEncoding.ASCII.GetString(decrypted));
        }
    }
}

Jak pewnie zauważyłeś sól przez mnie wygenerowana ma pewną słabość. Kiedy hasło będzie mieć mniej niż żądana ilość bajtów to dopełnienie będzie wypełnione zerami. Trzeba by jakoś to naprawić, żeby była większa losowość, bez konieczności zapamiętywania gdzieś soli ale dla przykładu wystarczy.

Generalnie:
Sól oraz IV możesz przechowywać jawnie, tj. dołączyć gdzieś do szyfrogramu i później sparsować najlepiej serializując taki obiekt:

public class Cryptogram {
    public byte[] encrypted { get; set; }
    public byte[] IV { get; set; }
    public byte[] Salt { get; set; }
}

PS: Nie musisz robić GenerateIV() czy GenerateKey(). Klucze są i tak tworzone z automatu więc to zbędne.

Dzięki za odpowiedź ;)
Nie jestem na tak wysokim poziomie, żeby ogarnąć całość twojego kodu bez patrzenia w google, ale chodzi o samą koncepcję, więc jest to zbędne ;)

Generalnie:
Sól oraz IV możesz przechowywać jawnie.

Czyli Sól i IV nie muszą być generowane dla każdej sesji losowo ? Mogą być statyczne ?
W internecie wyczytałem, że IV powinno być dla każdej sesji losowe, czyli to nie prawda ?

PS: Nie musisz robić GenerateIV() czy GenerateKey(). Klucze są i tak tworzone z automatu więc to zbędne.

Hasło sobie haszuje funkcją, którą wkleiłem wyżej ;)

PS: Dopuszcza się, żeby IV był taki sam, jak key ? (W sensie, że haszowany w ten sam sposób)

W szyfrowaniu najlepiej wykorzystywać wartości jednorazowe i jak najbardziej losowe. Wtedy jest to najmocniejsze. Jednorazowy klucz w moim algorytmie oznacza również resztę jednorazowych danych gdyż te dane są generowane na podstawie klucza (hasła tak naprawdę).

Można dodatkowo zastosować szyfrowanie kaskadowe tj. najpierw machnąć coś AES'em z kluczem a, natomiast później przejechać jeszcze raz ten szyfrogram 3DES'em z kluczem b itd. A przy dekryptażu kolejność odwrotna. Najważniejsze jest uzyskanie tzw. płaskiego histogramu. :)

Reasumując, coś takiego będzie w miarę bezpieczne ?
Funkcja "haszująca" hasło:

private static byte[] CreateKey(string InputKey)
{
    var key = new Rfc2898DeriveBytes(InputKey, saltBytes);
    return key.GetBytes(16);    
}

To co zwróci jest Key'em i IV, Sól jest statyczna.

Może tak być ?

Można dodatkowo zastosować szyfrowanie kaskadowe tj. najpierw machnąć coś AES'em z kluczem a, natomiast później przejechać coś 3DES'em z kluczem b itd. A przy dekryptażu kolejność odwrotna.

Też niezły pomysł ;)

Wydaje się ok ale zamiast tego magic number możesz wpisać aes.BlockSize / 8.

A czy klucz statyczny czy niestatyczny... Wszystko zależy od tego przecież co chcesz osiągnąć. Najlepiej wywalić klucz z pamięci jeżeli nie jest już potrzebny w programie. Ja tam bym tego statycznie nie robił, bo i po co?

PS: zapnij jeszcze wszystko ładnie z blok using. Klasa Rfc2898DeriveBytes dziedziczy tak naprawdę od IDisposable więc dobrze jest wywalić taki obiekt kiedy już zakończy swoją pracę.
Ewentualnie zrob key.Dispose();. To samo dotyczy obiektów klas szyfrujących rzecz jasna.

Cześć. na codeproject.com jest mnóstwo może kilkadziesiąt działających projektów po zadaniu frazy: AES w rozmiarze od 1 kB do 1 MB objętości

@grzesiek51114, dzięki za pomoc! ;)

@Vocall, oczywiście, że są, ale nie chodzi przecież o to, żeby kopiować kod, ja chcę się czegoś nauczyć ;P

Pozdrawiam! :D

@Zdziwiony: możesz zrobić jeszcze jeden myk i obiekt klasy AesCryptoServiceProvider utworzyć bezpośrednio w funkcji Encrypt w klauzuli using. Wtedy taki obiekt zostanie zwolniony automatycznie po zakończeniu pracy, a co za tym idzie również "jego" klucz, IV oraz sól. :)

Nie ma absolutnie żadnego sensu bieganie w kółko tylko dla zasady... Idea jest wszystkim znana od wynalazku Billa Gatesa: Windows... wielokrotnego wykorzystywania kodu... do czego Microsoft przecież włączył się aktywnie udostępniając kod a nawet bez Ich firma red gate dała nam narzędzie wglądu w kod platformy .NET...

proponuję skierowanie nakierowanie swojego wysiłku na biznesowe spojrzenie na dostępny kod: jak zarobić pierwszy miliard Euro... z ewentualnym pomysłem chętnie Ciebie zatrudnię...

Ale popatrz na to z innej strony. Jak nauczę się programować, jak nie robiąc tego ? Szczerze powiedziawszy jestem typem leniwej osoby, więc czytać "suchej teorii" nie chce mi się, masy podstaw języka pewnie nie znam, a pisząc programiki niejako zmusza mnie to do nauki tychże podstaw ;)

Biznesowe spojrzenie ? Hmm... Na to przyjdzie jeszcze czas, obecnie nikt mnie jeszcze nie zatrudni ;)

Wracając do tematu:
Chcę sprawdzać sobie poprawność hasła w taki sposób, że będę zawsze w jakimś nagłówku pliku trzymał słowo kontrolne, jeżeli ktoś wpisze złe hasło to słowo kontrolne po prostu nie będzie się zgadzać.
Bezpieczny to sposób na rozwiązanie tego problemu, czy nie za bardzo ?

Chcę sprawdzać sobie poprawność hasła w taki sposób, że będę zawsze w jakimś nagłówku pliku trzymał słowo kontrolne, jeżeli ktoś wpisze złe hasło to słowo kontrolne po prostu nie będzie się zgadzać.
Bezpieczny to sposób na rozwiązanie tego problemu, czy nie za bardzo ?

Nie. Zastosuj wyjątek do przechwycenia złego hasła. Zadziała tak jak w moim przykładzie. Jeżeli wpiszesz złe hasło do przy deszyfrowaniu zostanie wyrzucony wyjątek. Możesz zrobić specjalizację tegoż (a nie tak jak ja rzucając po prostu Exception) i kiedy pojawi się odpowiedni kod błędu napisać userowi stosowne info. Nie baw się w żadne kontrolne hasła etc.