Я хотел узнать как шифруются пакеты, как часто меняется ключ, как считается нагрузка на ключ, что происходит при потере пакетов, есть ли защита от replay attack, ну и все такое )
Просто у меня сложилось впечатление (возможно неверное), что шифрование тут сделано для галочки в отсутствии сформулированной модели угроз и не защищает от несанкционированного просмотра видео, например.
Использование функций шифрования не означает автоматического получения защиты данных.
Делаем самый простой вариант — Diffie-Hellman на эллиптических кривых
Вы потом выводите для каждого пакета новый ключ или просто мешинг делаете? Тогда как клиенты выводят ключи при потерях пакетов? Или каждый пакет независимо шифруете на сессионном ключе?
Если последнее, то, насколько я понимаю, управляющие пакеты довольно похожи и, с учетом меняющейся синхропосылки, можно довольно быстро подобрать ключ.
Если вдруг Amazon придет в РФ, то цены у них вполне может будут выше
И вполне возможно сам же Amazon начнет тогда лоббировать введение пошлин на доставку и ограничит деятельность мейлфорвардеров (например, перестанет отправлять на их адреса в США).
Я имею ввиду, что корпорации в первую очередь зарабатывают деньги. И если они придут в РФ, то халява может закончится.
Про «дешевизну Amazon» слегка преувеличили. На своем рынке он вовсе не самый дешевый, да и цены у них указаны без налогов, поэтому напрямую с РФ нельзя сравнивать.
Если вдруг Amazon придет в РФ, то цены у них вполне может будут выше, чем на том же Маркете сейчас. Сравните официальных дилеров Apple в РФ и в US — цены в РФ на Маркете сейчас бывают и пониже.
Но я буду покупать на Amazon в РФ, если им пользоваться будет также удобно как в US, и ассортимент будет сопоставим. Особенно мечтаю о доставке overnight. Фишка Amazon не в ценах, а в сервисе. Если Яндекс сможет сделать такой же сервис в РФ, то почему нет? Хотя я заранее не очень верю в это, т.к. начинать надо с малого и постепенно развиваться — тогда компания будет правильно реагировать на запросы пользователей. А если сразу по крупному и привлечением «эффективных менеджеров», то может выйти как с Кинопоиском.
P.S. Сначала тоже подумал, что хотят аналог AWS сделать )
Когда-то давно (лет 15 назад) решали подобную задачу для подписи проекций областей видимости видеокамер на карту местности. Такая проекция (в конкретной реализации) — это почти выпуклый многоугольник, который состоит не более, чем 255 вершин. Как он получается — это отдельная история и там много нюансов (например, если стоит здание, то часть области на условную поверхность земли не проецируется, а уходит в бесконечность). Почти — это значит, что геометрический центр всегда будет внутри многоугольника, хотя многоугольник при этом может и не быть выпуклым.
В математических терминах нужно было найти максимальный прямоугольник вписанный в такой «почти выпуклый» многоугольник. Использовали градиентный спуск для поиска максимума функции, начиная от геометрического центра. Нужно было искать и максимальный размер прямоугольника и оптимальную точку размещения его центра. Визуально результат был хорошим, но для большого количества объектов на карте, которые к тому же меняются со временем (камеры поворачиваются), алгоритм оказался не оптимальным и пришлось идти на некоторые ухищрения с кэшированием.
Уже позже случайно нашел научную статью, где такая задача решена за время, зависящее от количества вершин многоугольника. Но переписывать уже не стали, потому что и так все работало, да и процессоры стали быстрее.
Так, казалось бы простая задача, потребовала необычных исследований и расчетов. Было интересно.
Если совсем грубо, рукопожатия представляют собой обычный хэш типа md5.
Это правда совсем грубо. Ключ там получается путем 4096 раундов SHA1. Если быть точным, то формула такая: Key = PBKDF2(HMAC−SHA1, passphrase, ssid, 4096, 256)
Кстати, можно заметить, что замешивается название точки, поэтому при уникальном названии предвычисления не помогают. И это аргумент за то, чтобы менять название точки на свое.
Некоторое время назад тоже решил разобрать старые диски и даже комп 286 приобрел под это дело. Какие-то проекты удалось восстановить с дискет и их код попал на GitHub. Вот, например, редактор шрифтов под DOS, написанный на Паскале: github.com/codeatcpp/Font-Editor
Интересно, что дискеты до сих пор читаются, но на запись уже работают не идеально. Наверное процесс восстановления данных, особенно с 5'' дискет или с кассет DC600A — это отдельная тема.
Забавно (а скорее печально) тут то, что это — знакомый пример двухшаговой аутентификации (2-step verification — 2SV), которую часто ошибочно считают двухфакторной (2FV). И такая ошибка в переводе более существенна, чем безобидное расширение списка компаний.
ГОСТ на эту тему сейчас только разрабатывается, но есть же NIST SP 800-63b, где про это очень хорошо написано. И Mail.ru стоило бы более грамотно подходить к этому вопросу, в переводах в том числе.
Для написания коротких статей есть также и финансовая мотивация. Для публикации в серьезных изданиях, в том же Nature, надо платить немалые деньги за каждую публикуемую страницу. Другое дело, что попасть в Nature непросто, а со статьей в одну страницу — тем более.
Надо просто продавать одноразовые стаканчики со встроенным в верхнюю часть стенки чаем. Как только чуть отпил, то сразу процесс заваривания прекращается. Ну т.е. степень заварки автоматически определяется процессом начала использования.
Очень похоже на ошибку, которую мы обнаружили еще в VS2008 и она проявлялась во всех последующих версиях компилятора. На текущий момент она все еще в статусе Active.
Не один год просидел в ZEUS. Недавно начал писать тулзу, чтобы перетащить свой z80-код со старых 5" дисков в читаемом виде. Если интересно, код тулзы можно посмотреть на github. В Visual Studio Code результат выглядит так:
Кстати да. А если приглашают на face-to-face interview, то еще и за их счет можно побывать в разных странах. Ну а если совсем повезет, то получите контракт, по которому вам будут еще и платить за то, что вы там погружаетесь в англоязычную среду.
Интересный факт, но на страничке приложения Яндекс.Ключ нет версии для Windows Mobile. Также его нет в магазине приложений Microsoft. Вы работаете в Яндексе и у вас есть бета? )
Просто у меня сложилось впечатление (возможно неверное), что шифрование тут сделано для галочки в отсутствии сформулированной модели угроз и не защищает от несанкционированного просмотра видео, например.
Использование функций шифрования не означает автоматического получения защиты данных.
Вы потом выводите для каждого пакета новый ключ или просто мешинг делаете? Тогда как клиенты выводят ключи при потерях пакетов? Или каждый пакет независимо шифруете на сессионном ключе?
Если последнее, то, насколько я понимаю, управляющие пакеты довольно похожи и, с учетом меняющейся синхропосылки, можно довольно быстро подобрать ключ.
И вполне возможно сам же Amazon начнет тогда лоббировать введение пошлин на доставку и ограничит деятельность мейлфорвардеров (например, перестанет отправлять на их адреса в США).
Я имею ввиду, что корпорации в первую очередь зарабатывают деньги. И если они придут в РФ, то халява может закончится.
Если вдруг Amazon придет в РФ, то цены у них вполне может будут выше, чем на том же Маркете сейчас. Сравните официальных дилеров Apple в РФ и в US — цены в РФ на Маркете сейчас бывают и пониже.
Но я буду покупать на Amazon в РФ, если им пользоваться будет также удобно как в US, и ассортимент будет сопоставим. Особенно мечтаю о доставке overnight. Фишка Amazon не в ценах, а в сервисе. Если Яндекс сможет сделать такой же сервис в РФ, то почему нет? Хотя я заранее не очень верю в это, т.к. начинать надо с малого и постепенно развиваться — тогда компания будет правильно реагировать на запросы пользователей. А если сразу по крупному и привлечением «эффективных менеджеров», то может выйти как с Кинопоиском.
P.S. Сначала тоже подумал, что хотят аналог AWS сделать )
В математических терминах нужно было найти максимальный прямоугольник вписанный в такой «почти выпуклый» многоугольник. Использовали градиентный спуск для поиска максимума функции, начиная от геометрического центра. Нужно было искать и максимальный размер прямоугольника и оптимальную точку размещения его центра. Визуально результат был хорошим, но для большого количества объектов на карте, которые к тому же меняются со временем (камеры поворачиваются), алгоритм оказался не оптимальным и пришлось идти на некоторые ухищрения с кэшированием.
Уже позже случайно нашел научную статью, где такая задача решена за время, зависящее от количества вершин многоугольника. Но переписывать уже не стали, потому что и так все работало, да и процессоры стали быстрее.
Так, казалось бы простая задача, потребовала необычных исследований и расчетов. Было интересно.
Key = PBKDF2(HMAC−SHA1, passphrase, ssid, 4096, 256)Кстати, можно заметить, что замешивается название точки, поэтому при уникальном названии предвычисления не помогают. И это аргумент за то, чтобы менять название точки на свое.
Интересно, что дискеты до сих пор читаются, но на запись уже работают не идеально. Наверное процесс восстановления данных, особенно с 5'' дискет или с кассет DC600A — это отдельная тема.
ГОСТ на эту тему сейчас только разрабатывается, но есть же NIST SP 800-63b, где про это очень хорошо написано. И Mail.ru стоило бы более грамотно подходить к этому вопросу, в переводах в том числе.