[C#] Encryptie

[maniak]

Situatie: 2 front-ends achter ISA. In mijn code maak ik gebruik van RijndaelManaged om de querystring te encrypten (zie code). Op een lijst van ongeveer 400 links gebeurt het regelmatig dat bij de querystring het 1e deel "garbled" id, vaak zijn het dezelfde items. Dit duurt dan een paar minuten waarna het probleem weer is verholpen.

Hetgene wat encrypt wordt is een combinatie van een aantal strings. De encryptie is niet cruciaal, maar ik wil hiermee bereiken dat mensen geen dingen gaan proberen.

Ik kan echter niet het probleem vinden. De encryptie en decryptie geven geen foutmeldingen maar het 1e deel van de string is dan garbled. Wie of wie kan me vertellen wat er verkeerd gaat?

ps. de Key en Vector heb ik aangepast in het onderstaande voorbeeld..
ps2. de code had ik gevonden op het Internet en aangepast voor eigen gebruik..

C#:

public class AES
    {
        private byte[] Key = {  1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 };
        private byte[] Vector = { 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1};


        private ICryptoTransform EncryptorTransform, DecryptorTransform;
        private System.Text.UTF8Encoding UTFEncoder;

        public AES()
        {
              RijndaelManaged rm = new RijndaelManaged();

            EncryptorTransform = rm.CreateEncryptor(this.Key, this.Vector);
            DecryptorTransform = rm.CreateDecryptor(this.Key, this.Vector);

            UTFEncoder = new System.Text.UTF8Encoding();
        }

        public string EncryptToString(string TextValue)
        {
            return ByteArrToString(Encrypt(TextValue));
        }


        public byte[] Encrypt(string TextValue)
        {
 
            Byte[] bytes = UTFEncoder.GetBytes(TextValue);


            MemoryStream memoryStream = new MemoryStream();


            CryptoStream cs = new CryptoStream(memoryStream, EncryptorTransform, CryptoStreamMode.Write);
            cs.Write(bytes, 0, bytes.Length);
            cs.FlushFinalBlock();

            memoryStream.Position = 0;
            byte[] encrypted = new byte[memoryStream.Length];
            memoryStream.Read(encrypted, 0, encrypted.Length);

            cs.Close();
            memoryStream.Close();

            return encrypted;
        }

         public string DecryptString(string EncryptedString)
        {
            return Decrypt(StrToByteArray(EncryptedString));
        }

  
        public string Decrypt(byte[] EncryptedValue)
        {
            MemoryStream encryptedStream = new MemoryStream();
            CryptoStream decryptStream = new CryptoStream(encryptedStream, DecryptorTransform, CryptoStreamMode.Write);
            decryptStream.Write(EncryptedValue, 0, EncryptedValue.Length);
            decryptStream.FlushFinalBlock();

            encryptedStream.Position = 0;
            Byte[] decryptedBytes = new Byte[encryptedStream.Length];
            encryptedStream.Read(decryptedBytes, 0, decryptedBytes.Length);
            encryptedStream.Close();

            return UTFEncoder.GetString(decryptedBytes);
        }

        public byte[] StrToByteArray(string str)
        {
            if (str.Length == 0)
                throw new Exception("Invalid string value in StrToByteArray");

            byte val;
            byte[] byteArr = new byte[str.Length / 3];
            int i = 0;
            int j = 0;
            do
            {
                val = byte.Parse(str.Substring(i, 3));
                byteArr[j++] = val;
                i += 3;
            }
            while (i < str.Length);
            return byteArr;
        }

        public string ByteArrToString(byte[] byteArr)
        {
            byte val;
            StringBuilder sb = new StringBuilder();
            for (int i = 0; i <= byteArr.GetUpperBound(0); i++)
            {
                val = byteArr[i];
                if (val < (byte)10)
                    sb.Append("00");
                 else if (val < (byte)100)
                    sb.Append("0");

                sb.Append(val);
            }
            return sb.ToString();
        }
    } 

[RobIII]

maniak schreef op maandag 20 augustus 2012 @ 16:10:
De encryptie en decryptie geven geen foutmeldingen maar het 1e deel van de string is dan garbled. Wie of wie kan me vertellen wat er verkeerd gaat?

Zonder naar je code gekeken te hebben (heb je zélf überhaupt al gedebugged? (Debuggen: Hoe doe ik dat?)): weet je zeker dat de url ook correct URL encoded is? Heb je een voorbeeld/testcase van zo'n url (parameter) die het probleem reproduceert?

Wat me wel meteen opvalt aan de eerste paar regels code: Een IV hoort niet constant te zijn; deze genereer je per ding dat je encrypt opnieuw. Er is niets "geheims" aan dus die IV kun je prima opslaan of meesturen in de url oid. Voor zover mijn basis-encryptiekennis reikt althans. En dan kan die IV ook nog wel eens iets te maken hebben met "1e deel van de string is dan garbled" als ik dit zo lees; weet je zeker dat IV bij en- en decryptie identiek is? Ofwel: is dit stukje code "vereenvoudigd" om te posten hier of is dit precies je code?

[ Voor 49% gewijzigd door RobIII op 20-08-2012 18:30 ]

[pedorus]

Gezien de vreemde eigen encoding van de bytes in strings van 3 cijfers per byte denk ik niet dat dit het probleem is.

Ik snap enkel niet waarom je niet gewoon base64-encoding zou gebruiken. Verder zou ik AesManaged gebruiken (wellicht sneller als je standaard parameters hebt en logischer in een class AES). En er staat een goed voorbeeld van gebruik met minder tussenkopies en met net resource-gebruik bij MSDN: CryptoStream Class (System.Security.Cryptography).

Dus gooi wat je nu hebt weg, of lever een paar goede testcases aan, want dit gaat waarschijnlijk niemand voor je zitten te debuggen.

Overigens vraag ik me af of encryptie hier wel de bedoeling is, of dat er eerder een HMAC of andere authenticatie nodig is. Encryptie helpt niet tegen het wijzigen van de data in iets anders.

[maniak]

Ik heb zeker wel debugged, het probleem is dat het probleem zich alleen voordoet in de productie en ik kan het maar niet reproduceren op mijn ontwikkel omgeving. De IV vector kan prima constant zijn, dit is zelfs nodig als je machine 1 encrypt en machine 2 moet decrypten.. bij een verschillende IV vector zou dit onmogelijk zijn,

[RobIII]

maniak schreef op dinsdag 21 augustus 2012 @ 09:02:
De IV vector kan prima constant zijn, dit is zelfs nodig als je machine 1 encrypt en machine 2 moet decrypten.. bij een verschillende IV vector zou dit onmogelijk zijn,

Helemaal niet. Als je de IV maar gewoon ergens meestuurt van 1 naar 2 is er niets aan de hand. Er is, zoals ik zei, niets geheims aan een IV dus die kun je gewoon publiek meesturen.

quote: http://whatis.techtarget..../initialization-vector-IV

What is an initialization vector?

An initialization vector (IV) is an arbitrary number that can be used along with a secret key for data encryption. This number, also called a nonce, is employed only one time in any session.

The use of an IV prevents repetition in data encryption, making it more difficult for a hacker using a dictionary attack to find patterns and break a cipher. For example, a sequence might appear twice or more within the body of a message. If there are repeated sequences in encrypted data, an attacker could assume that the corresponding sequences in the message were also identical. The IV prevents the appearance of corresponding duplicate character sequences in the ciphertext.

The ideal IV is a random number that is made known to the destination computer to facilitate decryption of the data when it is received. The IV can be agreed on in advance, transmitted independently or included as part of the session setup prior to exchange of the message data. The length of the IV (the number of bits or bytes it contains) depends on the method of encryption. The IV length is usually comparable to the length of the encryption key or block of the cipher in use.

AFAIK is 't niet aan te raden een constante IV te gebruiken (en dus een variabele IV per message te gebruiken). Die IV kun je gewoon ergens (gangbaar, vziw, is om deze vooraan de encrypted data te "plakken") opslaan/meesturen.

[ Voor 64% gewijzigd door RobIII op 21-08-2012 09:10 ]

[maniak]

RobIII schreef op dinsdag 21 augustus 2012 @ 09:03:
[...]

Helemaal niet. Als je de IV maar gewoon ergens meestuurt van 1 naar 2 is er niets aan de hand. Er is, zoals ik zei, niets geheims aan een IV dus die kun je gewoon publiek meesturen.

De client moet niet de string decrypten plus de IV key is niet fixed maar gebruik niet de generateIV functie niet.

[RobIII]

maniak schreef op dinsdag 21 augustus 2012 @ 09:10:
De client moet niet de string decrypten

Dat boeit toch niet? Iets zal de string moeten decrypten (be it dezelfde server, een andere server of een kaboutertje, boeie). En dat iets zal de IV nodig hebben. Maar heb je pedorus in "\[C#] Encryptie" ook gelezen?

[ Voor 11% gewijzigd door RobIII op 21-08-2012 09:12 ]

[maniak]

Zoals ik al zei, de IV key is niet constant.. maar dat is niet de issue.. de issue is dat alles 95% van de tijd werkt maar af en toe dus niet.. Ik begrijp niet hoe het kan dat af en toe het niet werkt..

[RobIII]

maniak schreef op dinsdag 21 augustus 2012 @ 09:14:
Zoals ik al zei, de IV key is niet constant..

Nee, je zei de IV is niet fixed En daarbij zei je ook:

maniak schreef op dinsdag 21 augustus 2012 @ 09:02:
De IV vector kan prima constant zijn

En tot slot heb je in je code een constante IV staan:

C#:

private byte[] Vector = { 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}; 

Dus wat is 't nou? Hence ook mijn vraag:

RobIII schreef op maandag 20 augustus 2012 @ 18:17:
Ofwel: is dit stukje code "vereenvoudigd" om te posten hier of is dit precies je code?

Er is een verschil tussen constant en fixed Als 't over fixed gaat in deze context heb je 't doorgaans, afaik althans, over de size ervan (fixed size v.s. variable size).

maniak schreef op dinsdag 21 augustus 2012 @ 09:14:
de issue is dat alles 95% van de tijd werkt maar af en toe dus niet.. Ik begrijp niet hoe het kan dat af en toe het niet werkt..

Nou: zoals inmiddels al door mij en pedorus aangegeven: geef eens een testcase/data? We kunnen wel koffiedik gaan kijken maar zo gaan we er niet komen

Verder: pedorus en ik hebben je nog op andere zaken gewezen (o.a. URL encoding, alternatieve werkwijzen e.d.); als je daar eens mee aan de slag gaat of op reageert?

[ Voor 48% gewijzigd door RobIII op 21-08-2012 09:22 ]

[PolarBear]

maniak in "\[C#] Encryptie"
Het kan natuurlijk ook aan de ISA server liggen. Heb wel vaker problemen gezien met de config van de ISA server.

Vooral de onderstaande settings kunnen wel eens tot problemen lijden.

Verify normalization
You can select this checkbox to specify that requests with URLs containing escaped characters after normalization will be blocked. Normalization is the process where URL coded requests will be decoded. After decoding the URL the URL will be normalized again to be sure that no process is using the % character to encode a URL. If the HTTP Filter finds a difference in the URL after the second normalization, the requests will be rejected.

Block High bit character
URLs that contain Double Byte Characters (DBCS) or Latin1 will be blocked if this setting is active. An active setting regulary blocks languages that require more than eight bits to display all language specific characters.

[RobIII]

PolarBear schreef op dinsdag 21 augustus 2012 @ 09:36:
maniak in "\[C#] Encryptie"
If the HTTP Filter finds a difference in the URL after the second normalization, the requests will be rejected.

Dat verklaart 't gedrag niet dat TS beschrijft: "gebeurt het regelmatig dat bij de querystring het 1e deel "garbled" id"; deze beschrijving zegt dat de hele request dan rejected wordt.

PolarBear schreef op dinsdag 21 augustus 2012 @ 09:36:
Block High bit character
URLs that contain Double Byte Characters (DBCS) or Latin1 will be blocked if this setting is active.

Dat zou een mogelijkheid zijn (en ik sluit heel ISA als oorzaak overigens niet uit); maar ik neem aan (I know, iets met assumptions en fuckups) dat TS wel base64 oid gebruikt voor z'n encrypted data. Daar is DBCS niet aan de orde.

[edit]
Uhm, ik zie nu ByteArrToString en StrToByteArray. Zo te zien gebruikt 'ie geen base64 maar een andere "encoding" Echter, daar zijn DBCS ook niet aan de orde voor zover ik zie. Toch die assumption hé?

[ Voor 14% gewijzigd door RobIII op 21-08-2012 09:44 ]

[PolarBear]

RobIII schreef op dinsdag 21 augustus 2012 @ 09:42:

Dat zou een mogelijkheid zijn (en ik sluit heel ISA als oorzaak overigens niet uit); maar ik neem aan (I know, iets met assumptions en fuckups) dat TS wel base64 oid gebruikt voor z'n encrypted data. Daar is DBCS niet aan de orde.

[edit]
Uhm, ik zie nu ByteArrToString en StrToByteArray. Zo te zien gebruikt 'ie geen base64 maar een andere "encoding" Echter, daar zijn DBCS ook niet aan de orde voor zover ik zie. Toch die assumption hé?

Het is natuurlijk heel makkelijk uit te sluiten door of het vinkje uit te zetten of (beter) gewoon base64 encoding te gebruiken.

[pedorus]

maniak schreef op dinsdag 21 augustus 2012 @ 09:02:
Ik heb zeker wel debugged, het probleem is dat het probleem zich alleen voordoet in de productie en ik kan het maar niet reproduceren op mijn ontwikkel omgeving.

Je vertelde dat het begin van de gedecrypte string gegarbled was. Hier moet je toch een voorbeeld van hebben dan? Weet je zeker dat enkel het begin troep was, en niet de hele string? Weet je zeker dat het om het begin gaat, en niet om het einde wat logischer zou zijn? Weet je zeker dat niet iemand de boel zit te veranderen, om te kijken wat er gebeurd bij willekeurige inputdata (decryptie levert geen authenticiteit op)?

De IV vector kan prima constant zijn, dit is zelfs nodig als je machine 1 encrypt en machine 2 moet decrypten.. bij een verschillende IV vector zou dit onmogelijk zijn,

Als de IV wordt hergebruikt voor het encrypten van meer dan 1 message, dan kan bijvoorbeeld eenvoudig getest worden of de start hetzelfde is (in blocks). Dus stel dat je een string met een url hebt, dan kun je eenvoudig zien of de url naar (ongeveer) dezelfde site zal gaan of naar een andere site, omdat de geencrypte versie hetzelfde zal beginnen of juist niet.

[THA_ErAsEr]

First: Ik heb geen enkele ervaring met die encryptie

-een voorbeeld zou handig zijn
-valt er een regelmaat op, bij welke URL's dit gebeurd? Bijvoorbeeld de eerste 10 of diegene met speciale tekens ofzo
-als je een bepaalde URL meerdere keren ingeeft, geeft deze dan steeds hetzelfde resultaat?
-maak je overal je variabelen correct leeg? zodat er geen data blijft hangen van de vorige URL, naar de volgende?

Die zaken zou ik eerst eens nazien.
(Debuggen betekent niet alleen googlen, errors bekijken enzo, dat betekent ook testen en logisch nadenken.)

[RobIII]

THA_ErAsEr schreef op dinsdag 28 augustus 2012 @ 15:05:
First: Ik heb geen enkele ervaring met die encryptie

-een voorbeeld zou handig zijn

Daar was al (meermaals) om gevraagd

THA_ErAsEr schreef op dinsdag 28 augustus 2012 @ 15:05:
-als je een bepaalde URL meerdere keren ingeeft, geeft deze dan steeds hetzelfde resultaat?

Dat is nogal afhankelijk van hoe je je IV gebruikt en wanneer je een nieuwe IV gebruikt. Dat kan, bijv., zijn voor elke URL maar het kan ook zijn dat je de IV 1x per "sessie" maakt of...

[Infinitive]

Ik heb ooit jaren geleden eens gemerkt dat de inhoud van de IV-parameter gezero'd werd op onvoorspelbare momenten (na gebruik) wanneer de applicatie gebouwd was in de release configuratie. Veel meer kan ik me helaas niet meer herinneren.