Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| |
Что мешает поставить драйвер, который шифрует не на сервере, а локально, да еще любым алгоритмом, а потом уже зашифрованное кидает серверу! Надежней по-любому. 16.05.11 23:24 Число просмотров: 1881
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 16.05.11 23:25 Количество правок: 1
|
|
|
|
<site updates>
|
Борцы за приватность добрались до Dropbox 16.05.11 20:10
Publisher: dl <Dmitry Leonov>
|
Борцы за приватность добрались до Dropbox
InfoWorld http://www.infoworld.com/t/data-security/dropbox-caught-its-finger-in-the-cloud-cookie-jar-179
Популярный сервис хранения и синхронизации данных Dropbox [ http://www.bugtraq.ru/cgi-bin/bq.mcgi?id=164 ] вроде как поймали за руку - хоть обещается, что все сохраненные файлы шифруются AES-256, исследователи задались вопросом, у кого есть доступ к заветному ключу. И выяснилось, что если попытаться залить в Dropbox один и тот же файл с двух разных аккаунтов, объем данных при передаче второго файла будет значительно меньше - т.е. сервис борется с дублированием. Сработать это может лишь в том случае, если Dropbox'у известен ключ, которым был зашифрован файл - неважно, то ли там вообще один ключ на всех, то ли для каждого пользователя генерируется индивидуальный. Что противоречило утверждению из документации к системе, согласно которому "Dropbox employees aren't able to access user files, and when troubleshooting an account, they only have access to file metadata".
...
Полный текст
|
|
Они там все с ума посходили... )) 16.05.11 22:33
Автор: Den <Денис Т.> Статус: The Elderman
|
Все полученные от пользователя и зашифрованные на сервере данные, которые должны быть этим же сервером расшифрованы и переданы обратно пользователю, априори не могут быть приватными. )
Тут и опытов не надо, а поставленый опыт вообще не показателен, т.к. для передачи расшифрованных данных серверу в любом случае необходимо хранить эти данные в каком-то кеше, а алгоритм передачи сервера или алгоритм приема выкачивалки может проверять контрольные суммы файлов и не отправлять/принимать одно и то же несколько раз.
|
| |
Что мешает поставить драйвер, который шифрует не на сервере, а локально, да еще любым алгоритмом, а потом уже зашифрованное кидает серверу! Надежней по-любому. 16.05.11 23:24
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 16.05.11 23:25 Количество правок: 1
|
|
|
| | |
Что мешает... возможность делать общие папки. а так же возможность шарить файлы публично. ну, и как отметили - веб-морда. 17.05.11 18:35
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
| | |
ничто! только кто бы это сделал... )) 17.05.11 01:50
Автор: Den <Денис Т.> Статус: The Elderman
Отредактировано 17.05.11 01:54 Количество правок: 1
|
|
но проще создать архив под сложным паролем и можно выкладывать этот архив в полный свободный доступ. этот архив будет обладать большей приватностью, чем все те ресурсы, которые эту приватность обещают.
|
| | |
там есть веб-интерфейс и api, которым пользуется куча сторонних программ на всяких айфонах и андроидах 17.05.11 00:12
Автор: dl <Dmitry Leonov>
|
|
|
| |
ну да, про веб-интерфейс, через который передается ну никак не в aes, все явно забыли 16.05.11 22:56
Автор: dl <Dmitry Leonov>
Отредактировано 16.05.11 22:57 Количество правок: 1
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
