DEO>> кстати, а кто что думает над таким решением: DEO>> 1. используем метод шифрования "на лету" (то есть метод когда шифрование DEO>> в момент размонтирования происходит нам не подходит) > А что, бывает и такое? я порывшись по хаутушкам сперва именно на такой метод выпал: монтируют образ через loop а потом при размонтировании/монтировании криптуют/раскриптуют.
DEO>> маски-шоу могут оказаться рядом с сервером. DEO>> сервер как правило стоит в локалке ну и если ключ кому-то попадет то ему DEO>> еще надо узнать от какого он хоста зачем итп == вероятность маленькая DEO>> через эту дырку залезть. DEO>> адрес сервера логин пароль они легко запоминабельны. а ключ можно DEO>> держать длиннее самого длинного пароля. > Люди, занимающиеся криптографией, полагают, что эта схема ничуть не > надежнее просто пароля, только пароль в данном случае искусственно > дробится на три части - собственно пароль (к странице), логин и адрес > сервера. суть то в том что в случае маскишоу ключ с хостинга можно будет удалить заинтересованному неарестованному человеку :) > вот по параметру "доступность для нормальной работы" это решение куда хуже. > Ну, то есть понятно, что в случае чего ключ можно стереть на том сервере > - когда еще ребята в масках до него доберутся... Но его и локально > можно точно так же стереть - просто при покладании дать серверу сигнал о > такой вот специфической остановке. вот насколько я понимаю устроителей маскишоу то они так устраиваются чтобы никто никаких действий с серверами/компами произвести не успел. то есть локально его стереть нельзя. на хостинге может храниться CGI скрипт отдающий ключ и CGI-скрипт стирающий ключ с хостинга. то есть даже при терморектальном криптоанализе можно просто отдать логин и пароль той CGI-шки которая удалит ключ. а дальше уже даже сам при желании не расшифруешь свои же данные (если копия ключа единственная) > Как ты понимаешь, потеря данных в > таком случае должна быть необратима - если копия ключа где-то хранится, > ребята в масках ее получат. > Да. Оные же люди, занимающиеся криптографией, не рекомендуют делать > ключ "длиннее самого длинного пароля". Ключ делают _достаточной_ длины. а почему кстати не рекомендуют? интересны технические соображения -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
