|
| Опубликовано 29.10.2013 18:11 (10 лет назад) # |
CoderInTank написал:
Шифрование нужно, чтобы при перехвате трафика трудоемко было бы его прочитать. Если использовать для всех клиентов одинаковый ключ, то при компрометации этого ключа(путем декомпиляции, допустим), злоумышленнику легко можно будет расшифровать траффик всех клиентов. Если же генерировать и передавать незашифрованным ключ при каждой новой сессии, то при перехвате траффика этот ключ так же будет скомпрометированным и шифрование окажется бесполезным. Возможно я чего то не понимаю, как правильно делать то?
При ассиметричном шифровании: сервер раздает всем сертификат с публичным ключом, и приватный хранит у себя. Все клиенты знают публичный ключ. Если кто-то хочет передать данные на сервер, то он шифрует с помощью публичного ключа и спокойно передает. Только сервер может расшифровать на своем приватном ключе. Клиенты о сохранности публичного ключа не беспокоятся.
В реальности при ассиметричное шифрование дорого (CPU), поэтому сначала во время сессии обмениваются на ассиметрии другим симметричным ключом, на нем идет обмен данными и далее симметричный ключ уничтожается.
Это классическая схема. Есть куча ньюансов и особенностей, которые зависят от того, от каких атак хочется защищаться, кто за что отвечает, где какая информация должна храниться, сколько живут ключи и т.д.. В зависимости от этого подбираются протоколы (поведения всех субъектов взаимодействия), программные и аппаратные средства, организационные меры и пр.. Но это все глубже.
Есть схемы с симметричными ключами, позволяющие делать то, что ты хочешь. Но они более сложны и специфичны. >90% практических твоих случаев накрывает ассиметрия.
редакция от bsivko, 29.10.2013 18:12 |
|
|
|
|
| Опубликовано 29.10.2013 20:48 (10 лет назад) # |
Похоже это то, что надо, только судя по википедии нужно оперировать очень очень большими числами) Думаю в ручной реализации сделать все на куче маленьких(чтоб не возится с реализацией длинных чисел ) которые потом склеить в один ключ, хотя скорее всего это не имеет смысла если профи вознамерится сломать мою систему, он её сломает. А от непрофи этого будет достаточно. Принцип криптографии все же - сделать такую защиту стоимость взлома которой будет больше ценности содержимого.
А от асимметрии скорее всего откажусь, ибо дорого и искать либы для подключения не хочется. |
|
|
|
|
| Опубликовано 29.10.2013 22:32 (10 лет назад) # |
Диффи-Хеллман как раз таки первый алгоритм ассиметричной криптографии (;
Готовые библиотеки решают кучу проблем секьюрности, о которых вы даже не подозреваете. Но конечно, если хочется сделать на коленке свой велосипед, то можно и врукопашную. Алгоритмическо-математический опыт тож не помешает.
редакция от bsivko, 29.10.2013 22:36 |
|
|
|
|
| Опубликовано 25.06.2014 11:06 (10 лет назад) # |
| Кто нибудь кинет подборочку игр в которых стратегическая карта - планета, по типу Civilization, X-COM, игра про создание вируса(не помню как называется), Overpower? Хочется идей для игры такого плана.
редакция от MysticCoder, 25.06.2014 11:06 |
|
|
|
|
| Опубликовано 25.06.2014 12:02 (10 лет назад) # |
| 2MysticCoder - попробуй DEFCON и Uplink. А игра про создание вируса - скорее всего Plague Inc, или Pandemic\a. |
|
|
|
Инженер‑космогоник
|
| Опубликовано 25.06.2014 12:36 (10 лет назад) # |
MysticCoder
Посмотри light of Altair |
|
|
|
|
| Опубликовано 02.10.2014 17:57 (10 лет назад) # |
Возникла у меня идея, написать сервис по обмену голосовыми сообщениями... не в реалтайме, а по типу рации - записал, отправил.
Сначала идея распространилась на андроид девайсы, чтобы они как то обменивались голосом нужен сервак. На серваке соответственно мускул для хранения профилей юзеров, и программный сервак который будет рулить передачей голоса, сообщений, авторизацией и тп. Потом подумалось, что для этого дела надо будет поставить сайт, а раз будет сайт, то пусть поддерживает функциональность андроид приложения, то бишь записывать и отправлять голос. Потом подумалось, что раз будет сайт, то может он и сможет взять на себя все функции программного сервака?
Так как я не шибко шарю в разработке под андроид да сайтостроении, то соответственно вопрос: как все лучше организовать? структура, технологии которые нужно будет заюзать. Желательно, чтобы легко было освоить. |
|
|
|
Древний организм
|
| Опубликовано 03.10.2014 08:05 (10 лет назад) # |
| А чем не устраивают голосовая почта например? Все уже сделано и работает без интернета |
|
|
|
|
| Опубликовано 03.10.2014 09:17 (10 лет назад) # |
| Голосовой истаграм? |
|
|
|
|
| Опубликовано 03.10.2014 09:31 (10 лет назад) # |
| Тем, что это будет сервис. Главная задача которого не передать голос, а удовлетворить какие то потребности пользователя. Какие - пока раскрывать не буду :) |
|
|
|
Древний организм
|
| Опубликовано 03.10.2014 09:58 (10 лет назад) # |
| Секс по телефону изобретаешь что ли? :) |
|
|
|
|
| Опубликовано 03.10.2014 10:12 (10 лет назад) # |
Все то ты знаешь:) Подскажи лучше по вопросу)
С разработкой под андроид худо-бедно разберусь, уроков полно, а вот по части сервака не совсем все ясно как лучше организовать... Подозреваю, что если организовать по схеме андроид взаимодействует с сайтом через Get и Post запросы через какое то api, то при большой нагрузке будет хорошо тормозить. Может лучше сделать программный сервак, а сайт и андроид будут клиентами и общаться через сокеты? Вроде быстрее будет, да и при падении сайта андроиды продолжат работу, если разнести сайт и серв на разные машины. |
|
|
|
|
| Опубликовано 03.10.2014 11:16 (10 лет назад) # |
MysticCoder написал:
Подозреваю, что если организовать по схеме андроид взаимодействует с сайтом через Get и Post запросы через какое то api, то при большой нагрузке будет хорошо тормозить.
Не нужно беспокоиться. Это абсолютно нормальная практика. Взаимодействие через HTTP не сильно дороже чем сокеты, а разработка гораздо проще. Такой подход использует подавляющее большенство приложений. См. в торону RESTful - эдакая парадигма использования http для создания API. |
|
|
|
Древний организм
|
| Опубликовано 03.10.2014 11:20 (10 лет назад) # |
| Как раз про REST хотел сказать |
|
|
|
|
| Опубликовано 03.10.2014 19:30 (10 лет назад) # |
| Я щас может глупость скажу... А может использовать возможности облака? Стильно, модно, молодежно... |
|
|
|
|
| Опубликовано 04.10.2014 10:35 (10 лет назад) # |
| Вот насчет облака можно поподробнее...? А то я не шибко понимаю что это такое, и как это применить конкретно в этой задаче... |
|
|
|
|
| Опубликовано 04.10.2014 11:31 (10 лет назад) # |
Я думаю что не стоит заниматься преждевременной оптимизацей :) Нужно сначала разработать api, а потом уже этот бекенд можно будет пихать куда угодно. Хоть на виртуальный хостинг, хоть на VPS хоть в ОБЛАКО :)
Собственно не нужно считать что обако это какя-то панацея, решение всех проблем и самое лучшее решение для всего. На самом деле это просто "очень удобный и гибкий хостинг", в контексте размещения веб-приложений конечно.
Короче так: для начала можно все сделать и протестировать на обычном виртуальном хостинге. Когда пользователей появится достаточно много и ресурсов будет не хватать, то можно перейти на VPS. Когда и его ресурсы подойдут к концу и расходы будут оправданы доходами, то можно уже думать о строительстве облачной инфраструктуры :) |
|
|
|
|
| Опубликовано 04.10.2014 12:25 (10 лет назад) # |
| Может просветите, насчет сайта? Как лучше делать, какие языки использовать и тд... Насколько я понимаю, там раздельно логика - скрипты, пхп допустим, и раздельно верстка - то как сайт будет выглядеть, ну и скрипты соответственно в нужных местах подгружают как надо верстку и заполняют данными... |
|
|
|
|
| Опубликовано 04.10.2014 13:10 (10 лет назад) # |
Я бы посоветовал PHP - порог вхождения низкий, поддержка очень хорошая, развивается крайне активно, куча готовых решений и стандартная библиотке очень мощна :) Всякие хипстеры будут склонять ко всяким Ruby, Python'ам и прочит node.js'ам но не нужно их слушать :)
Принцип работы PHP очень прост. Когда пользователь запрашивает на сервере php файл, то он (файл) пропускается через интерпретатор. Все что находится внутри конструкции <?php ?> будет выполняться как PHP код, все что вне будет отдаваться браузеру как есть. Вот собственно и все разделение на верстку и логику. |
|
|
|
|
| Опубликовано 04.10.2014 15:10 (10 лет назад) # |
К сожалению, сам с облаками не работал, хотя и хочу, поэтому подробнее не могу.
Но судя по исходному запросу (хранить где-то удаленно звуковые записи), облако как раз подходит.
Просто мне кажется, это сейчас достаточно перспективное направление, чтобы его поизучать - может потом и в работе пригодиться. |
|
|
|