Проблема передачи зашифрованных данных мистика какая та...

← →
neodiX © (2004-05-09 04:08) [0]

Попробуйте взять любой алгоритм шифрования, например RC4 или BlowFish, закодируйте файл (текстовый,заполененый например всеми единицами, что бы потом легко можно было увидеть различия, размер 1.5 и более МБ) и попробуйте переслать его серверу (клиент -> сервер) (конечно же перед этим выслав ключ расшифровки). Или это у меня одного такая проблема или вы тоже увидете что данные в раскодированном файле отличаются от оригинала. Если весь опыт проводить на одном компе то все ОК, файлы совпадают, НО следует тока сервер поставить на другой физ. комп, то.. Я все проделывал используя ТCientSocket и TServerSocket в обоих режимах (blocking и non-blocking, результат один и тот же). Почему решил попробывать blocking режим? В начале подумал, что из за того, что клиент (посылающий) комп намного мощнее сервера, пока сервер обрабатывает/принимает данные, может быть утечка данных.. хотя не очень представляю как это может быть..

Одним словом: немогу переслать или принять зашифрованные данные. Может кто встречался с похожей ситуацией? Или попробуйте эмулировать похожее.. Заранее спасибо за мнения и ответы.

p.s. сырцы не даю (хотя если надо могу выложить) т.к. там все точно так же как при посылки простого файла, тока перед этим он шифруется.
Кстати, если файл не шифровать все ОК.

← →
Torin © (2004-05-09 09:34) [1]

Интересная ситуация, прямо таки действительно МИСТИКА. Ведь если "Кстати, если файл не шифровать все ОК." то значит передаётся всё правильно, косяк в расшифровке. Данные передаются как данные сетевуха не знает шифрованые они или нет (да и никто кроме тебя не знает) так что намерено нагадить вряд ли кто может :-). Но чтобы на 200% убедиться ,что собаку ты пытаешься откопать там где её нет сравни зашифрованый файл на компе получателе (до расшифровке) и на отправителе...что одинаковые? :-)

← →
Piter © (2004-05-09 15:35) [2]

код передачи и приема данных в студию

← →
Anatoly Podgoretsky © (2004-05-09 15:42) [3]

Нет ли плпытки передавать как текстовые данные?

← →
Reindeer Moss Eater © (2004-05-09 15:46) [4]

Никакой мистики нет.
Если исходить из анамнеза (дешифровка локально идет успешно, нешифрованный файл принимается без искажений) то диагноз таков:
Неправильно передаешь/принимаешь ключ.
Вот и все.

← →
neodiX © (2004-05-09 15:54) [5]

2 Anatoly Podgoretsky:
в каком смысле? имеете ввиду я делаю socket.sendtext? нет, использую sendbuf.

Вот сейчас заметил одну вещь, попробывал как посоветовал Torin. Перед посылкой зашифрованного файла, сохранил его на диск, при получении сохранил только ключ для расшифровки, собрал весь файл (Torin: да они одинаковые) и расшифровал его используя переданный ключ. Все прошло корректно, файл совпадает с оригинальным. Как я понимаю, у меня проблема в поблочной расшифровке..

2 Piter: еще часок другой посижу поразбираюсь, если не исправлю - код будет в студии.

← →
neodiX © (2004-05-09 15:58) [6]

2 Reindeer Moss Eater:

Ключ то передается тока один раз, в самом начале и потом используется для расшифровки блока...

ОК, если не разберусь в течении полу часа, будем разбирать код :)

← →
Reindeer Moss Eater © (2004-05-09 16:02) [7]

Да фик ли тут разбираться?
Дамп ключа на клиенте перед отправкой и дамп этого же ключа на сервере после приема.
Находим 10 различий или начинаем верить в Деда Мороза и Снегурочку.

← →
Reindeer Moss Eater © (2004-05-09 16:05) [8]

Либо у тебя при передаче файлов методы передачи заточены под ASCII символы и неправильно работают с двоичными данными

← →
neodiX © (2004-05-09 16:38) [9]

2 Reindeer Moss Eater:
Дампы полностью совподают, иначе как может быть, что когда я на сервере делаю tracing приема файла (т.е. делаю задержку посылки данных, т.к. сокеты блокируещие) и вижу как поблочно сразу же расшифровывается, притом результат отличный, все работает! НО стоит мне тока не делать Tracing, т.е. просто принять без задержок все блоки, как в результате файл выходит с такими (http://www.pastebin.com/64333) врезками!

Меня тут волнует одна вещь, не зря наверно ты и AП заговорили про текстовые данные... вы хотите сказать что так незя делать:

// код посылки данных

//в начале ключ посылаю var s:string; keys:tkey128; begin GenerateRandomKey(keyS,SizeOf(keyS)); setlength(s,16); move(keyS,s[1],16); TcpClient1.SendBuf(s[1],length(s)); //потом файл var stream:tfilestream; command,temp:string; outcount:longint; //ins,outs:tmemorystream; i:integer; s:string; begin Stream := TFileStream.Create("d:\data.txt", fmOpenRead or fmShareDenyWrite); stream.Position:=0; command:="Failas,haja.txt,"+inttostr(stream.Size)+","; setlength(temp,(length(command) div 8)*8+8); blowbuf(command[1],length(command),temp[1],outcount,keys,true); //заголовок TcpClient1.SendBuf(temp[1],length(temp)); setlength(temp,0); setlength(command,stream.size); stream.Position:=0; stream.Read(command[1],stream.Size); stream.Free; setlength(temp,(length(command) div 8)*8+8); blowbuf(command[1],length(command),temp[1],outcount,keys,true); //сохраняю зашифр. файл ins:=tmemorystream.Create; ins.Write(temp[1],length(temp)); ins.Position:=0; ins.SaveToFile("d:\encodedData.txt"); ins.Free; TcpClient1.SendBuf(temp[1],length(temp)); end;

← →
neodiX © (2004-05-09 19:25) [10]

для полной картины вот код сервера:

procedure TForm1.ServerSocket1GetSocket(Sender: TObject; Socket: Integer; var ClientSocket: TServerClientWinSocket); begin ClientSocket := TServerClientWinSocket.Create( Socket, ServerSocket1.Socket ); end; Procedure TServerSockThread.ClientExecute; var //Buffer: array[0..1024*5-1] of Char; // ReplyBuf : string; LenReceived : integer; s:string; filename:string; filesize:longint; failas:TFilestream; temp:string; outcount:longint; begin outcount:=0; SockStream := TWinSocketStream.Create(ClientSocket, 60000); while (not Terminated) and (clientsocket.Connected) do begin s:=""; if SockStream.WaitForData(1000) then begin try SetLength( s, 5120); LenReceived := SockStream.Read( s[1], Length(s)); setlength(s,lenreceived); if lenreceived>0 then begin if first then begin move(s[1],key,16); first:=false; continue; end; setlength(temp,(length(s))); blowbuf(s[1],length(s),temp[1],outcount,key,false); setlength(temp,outcount); if gauti then begin //getting file try failas.Write(temp[1], length(temp)); if failas.Size>filesize then begin form1.Memo1.Lines.Add("size > filesize"); break; end; if (failas.Size = FileSize) then begin form1.Memo1.Lines.Add("end"); Failas.Position:= 0; FreeAndNIL(Failas); gauti:=false; end; except Failas.Free; end; continue; end; //end getting file //^^^^^^^^^^^^^^^^^^ Recieving file ^^^^^^^^^^^^^^^^^^^^^^ if copy(temp,1,6)="Failas" then begin delete(temp,1,7); filename:=copy(temp,1,pos(",",temp)-1); delete(temp,1,pos(",",temp)); filesize:=strtoint(copy(temp,1,pos(",",temp)-1)); delete(temp,1,pos(",",temp)); if FileExists("c:\"+filename) then begin randomize; filename:="New"+inttostr(random(10000))+"_"+filename; end; failas:= TFileStream.Create("c:\"+filename,fmcreate); gauti:= true; end; //if header was combined with data if gauti then begin //getting file try failas.Write(temp[1], length(temp)); if (failas.Size = FileSize) then begin Failas.Position:= 0; FreeAndNIL(Failas); gauti:=false; end; except Failas.Free; end; end; //end getting file end else begin ClientSocket.Close; terminate; break; end; except on E:Exception do begin clientsocket.Close; terminate; break; // stream read error, unexpected disconnect, ... end; end; //end try end //end waitfor end; Failas.Position:= 0; FreeAndNIL(Failas); FreeAndNIL(SockStream); end;
outcount - возвращает реальное число раскодированных байтов, т.к. числов закодированных байтов всегда кратно 8.

все же не могу понять в чем проблема...

← →
Verg © (2004-05-10 08:43) [11]

> SetLength( s, 5120);
> LenReceived := SockStream.Read( s[1], Length(s));
> setlength(s,lenreceived);
>
//Я так понимаю, что ты расчитываешь на какаие-то
//определенные размеры принятых порций
> if lenreceived>0 then begin
>
> if first then begin
> move(s[1],key,16);
> first:=false;
> continue;
//Хм. А если принялось меньше 16 байт, то ключ будет неверным
//Если принялось больше 16-ти, то ключ будет верным, но часть
//данных будет потеряна
> end;
>
> setlength(temp,(length(s)));
> blowbuf(s[1],length(s),temp[1],outcount,key,false);
//Расшифровка какими порциями допустима? Кратными 8-ми?
> setlength(temp,outcount);

Есть предположение, что ты расчитываешь на строгое соответствие размеров передаваемых порций по SendBuf размерам принимаемых порций SockStream.Read. Для TCP расчет на это неверен в принципе.

← →
neodiX © (2004-05-10 11:31) [12]

2 Verg

> //Хм. А если принялось меньше 16 байт, то ключ будет неверным
> //Если принялось больше 16-ти, то ключ будет верным, но
> часть
> //данных будет потеряна

По поводу ключа я не переживаю, т.к. в данном случае я его пересылаю первым, нажав на кнопку, а потом сам файл, т.е. ключ точно равен всем 16 байтам не больше не меньше. Конечно в проге это будет не так и это надо будет контролировать. Но вот в этом месте:

> //Расшифровка какими порциями допустима? Кратными 8-ми?
Есть предположение, что ты расчитываешь на строгое соответствие размеров передаваемых порций по SendBuf размерам принимаемых порций SockStream.Read. Для TCP расчет на это неверен в принципе.

ты полностью прав! Этим уже можно обьяснить тот факт, что когда я принимаю данные "tracing"ом" то все ОК, а когда нет - то... В реал тайме пакеты же не посылаются так красиво, все например по 5120б...По той причине можно обьяснить, почему, когда принимается весь файл вначале, а потом весь расшифровывается, то все ОК..

Как я понимаю выходы в этой ситуации:
1) контролировать размер передаваемых данных (или сделать задержку передачи sleep"ом или попробывать поиграть с буффером setsockopt) - но думаю этот вариант отпадает..

2) послать в начале весь закодированный файл, а потом его расшифровать - это выход, притом уже работает :)

другое тут вряд ли можно придумать..

Verg спасибо за помощь!

Надо пострить алгоритм приема таким образом, чтобы в нем не было заложено никаких предположений о количестве принятых ф-цией SockStream.Read(..., Count) данных, кроме таких, что оно д.б. >0 и <=Count, а если =0, то произошел разрыв соединения.

Да, я понял. Еще раз спасибо.

Информация к размышлению:
в моем ведении есть сетка, с одним компом весьма интересная картина: при передачи/отправки на/с него файлов больше некоторого "магического" размера (ок. 120 Мб) происходит любо зависание компа, либо просто отключается сеть на нем (иногда до перезагрузки, иногда на неск.сек.). Железо перебирал (в частности сетевухи менял), Win2000 переустанавливал на свежий винт. Более того содержимое файлов непонятным образом меняется (проверено на NRG образе игры). Форумы обходил, дрова менял....
в общем, разве что пайки на материнке не освежал %-])
в остальном, (единичные файлы .doc и клиент-серверная БД) бегает нормально. Так-то!

Вообще-то для своих вопросов нужно создавать свои топики.

У тебя с виртуальной памятью все в порядке? Не маловато-ли?
Как ты посылаешь, по TCP? Как ждешь завершения?

Мое предположение: ты шлешь файлы без приема подтврерждений от клиента, соответственно, не регулируешь скорость отправки (читай: постановки в очередь на отправку), и при определенных объемах просто исчерпываешь доступную виртуальную память.

← →
Роман (2004-05-11 09:06) [17]

RC-алгоритмы - блочные. Это значит, что их можно применять симметрично только к единому блоку данных, в общем случае, кратному минимальному окну. Т.е. расшифровать файл достоверно можно только после того, как его полностью принял.

2 Роман:
вы поставили все точки над моими догадками.. да, в криптологии я не силен, поэтому толька догадывался что дело может быть в блочном шифровании..

Проблема передачи зашифрованных данных мистика какая та... Найти похожие ветки