28. december 2010 - 16:02Der er
17 kommentarer og 1 løsning
problem med dekryptering af streng
Hejsa
Jeg har siddet og fumlet lidt med at få krypteret en streng og så sende den via en socket forbindelse og dernæst dekryptere den, men jeg får en exception om at strengen har en ugyldig længde... eks 23byte
Når strengen ankommer krypteret er den på et lige antal byte men efter konverteringen til et bytearray er der nu et ulige antal byte.
Message er på 32byte! // Step 4. Convert the input string to a byte[] byte[] DataToDecrypt = Convert.FromBase64String(Message);
Fejler så her på længden som nu er på 23byte Results = Decryptor.TransformFinalBlock(DataToDecrypt, 0, DataToDecrypt.Length);
Håber nogen kan gennemskue problemet!
Jeg tror det har noget at gøre med ToBase64String/FromBase64String
M.v.h
Tue
Hele metoden:
public string DecryptString(string Message, string Passphrase) { byte[] Results; System.Text.ASCIIEncoding ASCII = new System.Text.ASCIIEncoding();
// Step 1. We hash the passphrase using MD5 // We use the MD5 hash generator as the result is a 128 bit byte array // which is a valid length for the TripleDES encoder we use below
MD5CryptoServiceProvider HashProvider = new MD5CryptoServiceProvider(); byte[] TDESKey = HashProvider.ComputeHash(ASCII.GetBytes(Passphrase));
// Step 2. Create a new TripleDESCryptoServiceProvider object TripleDESCryptoServiceProvider TDESAlgorithm = new TripleDESCryptoServiceProvider();
Jeg er kommet lidt videre... det er måske noget helt andet der er problemet!
Når jeg sender krypteret strenge langsomt, så virker det fint og strengen er så på 44byte, men hvis jeg sender dem "HURTIGT" 600/sec får jeg strenge af meget forskellig længde og data er selvfølgelig korrupt!
Jeg sidder på et lokalt netværk med 2 pc'er, så jeg kan ikke tro det skulle give problemer at sende 26400 bytes/sec.
Herunder koden:
send data:
public void SendData(String Value, Boolean ErrorFlag, String Message) { try { ns = new NetworkStream(server); sw = new StreamWriter(ns); string Data = "<START>"+Value+";"+ErrorFlag.ToString()+";"+Message+"<END>"; if ((Data.Contains("+"))||(Data.Contains(" "))) {}
/// <summary> /// Method watch the stream for available server-data /// </summary> public void ServerDataAvailable() { sr = new StreamReader(ns); ns = new NetworkStream(client);
Det er svært at gennemskue bare ved at læse koden. Du må igang med at troubleshoote.
Start med at udskrive: * det base64 der sendes * det base64 der modtages * længden af byte[] inden konvertering til base64 * længden af byte[] efter konvertering fra base64
Jeg bruger ASCII fordi det kun er ASCII karakter der skal sendes, men mit problem er dog det samme hvis jeg bruger UTF8.
Jeg er kommet lidt nærmere problemet.
Hvis jeg stepper gennem koden virker det fint, men når jeg slipper koden løs og der sendes 600 strenge i sekundet går det helt galt.
MEN hvis jeg f.eks sender strengen "123456789.10.11.12.13.14.15.16.17.18.19.20.21.2" som har samme længde som den krypteret streng køre det bare der ud af uden tab
Jeg tænkte på om der i den krypteret streng kunne ligge nogle \r\n i data, som min StreamReader jo bruger til at hente data fra NetworkStreamen
Men det harmonere jo ikke med at data er ok når det går langsomt!!!
Data der sendes er altid ok... ved modtagelse også hvis der ikke sendes for "hurtigt" data.
Han mente nok bare at måden du greb det an, ikke var super systematisk.
Men nu siger du jo også at du har fundet problemet ... så skal du bare finde ud af hvad den læser ... altså hvorfor du ikke får hele din streng. Det er vel næste step.
I stedet for at step gennem kode, da der så automatisk kommer delay, må du jo lave en logger ... så du kan se det når det kører med full speed og finde ud af hvorfor, din ReadLine ikke virker som du regner med den skal.
ReadLine tror jeg nu også kun læser til enden af filen. Hvis der kun er en linje i den, så er der jo ingen "\r\n" til slut, så måske der dit problem er ... :-)
Det kan da godt være at jeg giver en dåse sodavand til dem der kommer fordi, når jeg paserer 1 million point, men jeg tror ikke at der er nogen som lige kigger forbi.
Jeg gætter iøvrigt på at det først sker engang i oktober-november.
Kunne man i øvrigt ikke sagtens forestille sig, at der i din Send-metode gemmer sig et par IOExceptions, som du så nydeligt ignorerer? Hvis ikke du kan håndtere den alligevel, bør du ikke pakke din metode ind i en try/catch. Under alle omstændigheder bør du ihvertfald /som minimum/ skrive exception'en ud til Debug eller Trace.
Jeg har fået løst problemet...men jeg kan ikke lige sætte en finger på hvad der gik galt, selv om jeg lavede en log, hvor der manglede data eller muligvis henter StreamReader'en data i mindre bidder, så alt kommer ud af sync.
Jeg skrev koden om så der ikke var kryptering og så virkede det igen , så indførte jeg krypteringen igen og siden har der ikke været problemer. Har dog også tilføjet en linie der rydder inputbufferen på streamreaderen når der sendes en ny kommando... det kunne også gøre en forskel.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.