А почему не платой ГСЧ на мат.плате, или ранодомными нажатиями на клавиатуре-мышке (кто-сталкивался с PGP, поймёт)?
2) ошибка использования криптозащиты: «Для каждой ключевой пары RSA, которую мы будем генерировать, мы так же будем генерировать случайную ключевую пару Curve25519, а потом считать общий секрет от публичного ключа этой пары и нашего приватного»
А такой-уж ли «секретный» будет наш общий секрет? Мне кажется это все напомоинает мне способ поместить публичный и приватный ключ в один контейнер, а потом выдать его за приватный.
Ребят вы просто не читали оба труды по нейрофизиологии за последний год. Карта для ориентирования на местности в гиппокампусе однозначно двумерна, однако зоны тактильного восприятия — это полноценное 3D. Если брать проекцию многомерного пространства — например руки (с множеством степеней свободы), то ваш мозг отлично справится с 3D проекцией этого N-мерного пространства, чтобы вы могли, к примеру, неглядя пошариться и достать рукой до вкуского банана в рюкзаке за спиной. (Ну, у кого что). Вообще вы в динамике обрабатываете N-мерную информацию с ваших «датчиков», в 4Д информацию — карту 3-Д пространства с прогнозированием нахождения 3D-объекта во времени, и обратно для преобразования в N-мерный поток сигналов для управления телом кажлый день в пробке, в метро, на автомобиле и т/д.
Так что не надо лепить гобатого — вы всё прекрасно умеете.
Если вы этого не осознаёте — так это вам же во благо — иначе ваш маленький мозг (по сравнению с мозгом слона, к примеру) из сотояния покоя (задействованы 2-6% неронов) превратился бы в кипящий ад (задействованы 60-80% нейронов), правда, ненадолго — минут на 5-7 — и просто вы бы умерли или впали в состояние комы.
Выношу обьяснение №2, почему формат TREE не является бинарно-безопасным.
Без использования магических констант-разделителей, этот формат не является бинарно-безопасным, так как множество входных символов алфавита этой грамматики входных данных не должно включать символы-разделители, используемые в этом формате, чтобы избежать неоднозначной интепретации данных.
Обьяснение
Просто добавим поле с «проверочным» значением, «контрольная сумма», или, если хотите, избыточную информацию, равную самому форматированному TREE потоку данных, но без этой контрольной строки, чтобы избежать бесконечно длинного потока данных. Так как все последующие переносы строк нарушат структуру данных, то обратная процедура с декодированиеи этого потока обречена на провал, так как всегда будет существовать по крайней мере одна структура, которая будет неправильно интерпретирована при корректных входных данных, вне зависимости от сложности алгоритма обработки этих данных.
И без использования 0A 0D (в миру более известны как \r \n) этот формат не является истинно бинарно-безопасным, так как множество входных символов алфавита этой грамматики входных данных не должно включать символы-разделители, используемые в этом формате, чтобы избежать неоднозначной интепретации данных.
Просто добавим поле с «проверочным» значением, «контрольная сумма», или, если хотите, избыточную информацию, равную самому форматированному TREE потоку данных, но без этой контрольной строки, чтобы избежать бесконечно длинного потока данных. Так как все последующие переносы строк нарушат структуру данных, то обратная процедура с декодированиеи этого потока обречена на провал, так как всегда будет существовать по крайней мере одна структура, которая будет неправильно интерпретирована при корректных входных данных, вне зависимости от сложности алгоритма обработки этих данных.
Формат TREE не является в подлинном смысле бинарно-безопасным форматом.
Лулз пакета в том, что если бы формат действительно был бинарно-безопасным, то разделители 0D могли бы входить в двоичную последовательность в паре ключ — значение, а иначе — это ложное утверждение. Данный формат не является бинарно-безопасным, так как нет механизма подсчёта длины двоичных данных в паре ключ-значение, а следовательно, формат является контекстно-зависимым
Я могу вас разочаровать, но ваша гипотеза относительно JSON и TREE неверна абсолютно. С чего вы взяли, что при потере произвольной части данных все будет воспринято как норма? Всё будет воспринято как норма при удалении всего блока в потоке данных между символами 0D, включая один из символов, или внутри пары (=,0D). При таких-же ошибках в передача данных это сообветствует потере байт в JSON внутри значения, или потере списка. Это абсолютно одинаковая вероятность ввиду взаимно — однозначного маппинга структуры управления JSON — TREE, и, вследствие этого — равной вероятности ложноположительного срабатывания фильтра ошибок (ошибка при потере данных присутствует, но не будет обнаружена)
Этот стиль кодинга напоминает мне очень хорошо знакомый мне стиль «говнокодинга».
Основные особенности стиля:
-при форсмажоре разработчика — отпуск, увольнение (как правило, единственного) всё перестает работать и переписывается
-как правило, код выглядит простым, но совершенно невозможным (невероятно сложным) при удалённой отладке
-после переписывания стандартыми средствами («чистый» C#, без межплатформенных вызовов и т/д), код становится более
1) портируемым
2) читаемым
3) отлаживаемым
Парни, вы меня удивляете. Каждый раз, когда кто-нибудь изобретает велосипед с квадратными колесами, никто не спрашивает себя а как это будет работать в продакшене.
Во-первых, код не компилируется — не преведена реализация EntityPtr. Во-вторых, та реализация, которая существует (http://habrahabr.ru/company/luxoft/blog/219619/) — не работает на Mono. (До свидания, мой маленький Apple, до свидания до новых встреч!)
В третьих, ну неужели опять кому-то пришло в голову, что использование доменов приложения (как полагаю, уже исключительно на платформе Windows) — тормозит из-за сериализации? Ну, не делайте сериализацию — кто мешает. Но делайте стандартыми средствами, а не с использованием бубна.
Ну, реально — работает только на некоторых платформах на базе ОС Windows, а как только что-то поменяется компилятор, сборщик мусора — ваше глючное, непродуманное решение можно будет выкинуть в трубу. Да, по поводу платформы Windows — это решение не будет работать в средах (.NET) с настроенной параллельной сборкой мусора в отдельном потоке, например в ASP.NET приложениях, серверах Windows Server и т.п.
swf-технология сама по себе — огромная дыра в безопасности, так как используется activex-технология а не sandbox, в котором все процесс работают изолированно от родительского процесса
Винтик заело — меняем всю машину? Или: у сотрудника горе — увольняем нафиг — потому что он не хочет работать, когда его личный мир рушится.
ОКЭЙ, сэр.
Ну тогда нужно применить это же самое правил на самих, менеджеров высшего звена:
Почему менеджеры высшего звена не адаптируются к своему стратегическому ресурсу (что не приводит к повышению эффективности работы этого самого стратегического ресурса — людей) для повышения эффективности его работы?
Схлоапываем все 4 пункта, по аналогии — вывод: не хотят!
Батенька, вы не в нефтянке менеджером случайно работаете, чтобы так транжирить ресурсы?
1) ошибка выбора ГПСЧ: «Нам нужен ГПСЧ, который инициализируется секретным значением»
А почему не платой ГСЧ на мат.плате, или ранодомными нажатиями на клавиатуре-мышке (кто-сталкивался с PGP, поймёт)?
2) ошибка использования криптозащиты: «Для каждой ключевой пары RSA, которую мы будем генерировать, мы так же будем генерировать случайную ключевую пару Curve25519, а потом считать общий секрет от публичного ключа этой пары и нашего приватного»
А такой-уж ли «секретный» будет наш общий секрет? Мне кажется это все напомоинает мне способ поместить публичный и приватный ключ в один контейнер, а потом выдать его за приватный.
Так что не надо лепить гобатого — вы всё прекрасно умеете.
Если вы этого не осознаёте — так это вам же во благо — иначе ваш маленький мозг (по сравнению с мозгом слона, к примеру) из сотояния покоя (задействованы 2-6% неронов) превратился бы в кипящий ад (задействованы 60-80% нейронов), правда, ненадолго — минут на 5-7 — и просто вы бы умерли или впали в состояние комы.
it-ua.info/news/2015/01/19/unity-ui-u-vers-46.html#cut
НЕНАВИЖУ!
Без использования магических констант-разделителей, этот формат не является бинарно-безопасным, так как множество входных символов алфавита этой грамматики входных данных не должно включать символы-разделители, используемые в этом формате, чтобы избежать неоднозначной интепретации данных.
Обьяснение
Просто добавим поле с «проверочным» значением, «контрольная сумма», или, если хотите, избыточную информацию, равную самому форматированному TREE потоку данных, но без этой контрольной строки, чтобы избежать бесконечно длинного потока данных. Так как все последующие переносы строк нарушат структуру данных, то обратная процедура с декодированиеи этого потока обречена на провал, так как всегда будет существовать по крайней мере одна структура, которая будет неправильно интерпретирована при корректных входных данных, вне зависимости от сложности алгоритма обработки этих данных.
Просто добавим поле с «проверочным» значением, «контрольная сумма», или, если хотите, избыточную информацию, равную самому форматированному TREE потоку данных, но без этой контрольной строки, чтобы избежать бесконечно длинного потока данных. Так как все последующие переносы строк нарушат структуру данных, то обратная процедура с декодированиеи этого потока обречена на провал, так как всегда будет существовать по крайней мере одна структура, которая будет неправильно интерпретирована при корректных входных данных, вне зависимости от сложности алгоритма обработки этих данных.
Лулз пакета в том, что если бы формат действительно был бинарно-безопасным, то разделители 0D могли бы входить в двоичную последовательность в паре ключ — значение, а иначе — это ложное утверждение. Данный формат не является бинарно-безопасным, так как нет механизма подсчёта длины двоичных данных в паре ключ-значение, а следовательно, формат является контекстно-зависимым
Основные особенности стиля:
-при форсмажоре разработчика — отпуск, увольнение (как правило, единственного) всё перестает работать и переписывается
-как правило, код выглядит простым, но совершенно невозможным (невероятно сложным) при удалённой отладке
-после переписывания стандартыми средствами («чистый» C#, без межплатформенных вызовов и т/д), код становится более
1) портируемым
2) читаемым
3) отлаживаемым
и, самое главное — как правило — более быстрым.
Во-первых, код не компилируется — не преведена реализация EntityPtr. Во-вторых, та реализация, которая существует (http://habrahabr.ru/company/luxoft/blog/219619/) — не работает на Mono. (До свидания, мой маленький Apple, до свидания до новых встреч!)
В третьих, ну неужели опять кому-то пришло в голову, что использование доменов приложения (как полагаю, уже исключительно на платформе Windows) — тормозит из-за сериализации? Ну, не делайте сериализацию — кто мешает. Но делайте стандартыми средствами, а не с использованием бубна.
Ну, реально — работает только на некоторых платформах на базе ОС Windows, а как только что-то поменяется компилятор, сборщик мусора — ваше глючное, непродуманное решение можно будет выкинуть в трубу. Да, по поводу платформы Windows — это решение не будет работать в средах (.NET) с настроенной параллельной сборкой мусора в отдельном потоке, например в ASP.NET приложениях, серверах Windows Server и т.п.
В общем, энтерпрайз сказал своё слово
ОКЭЙ, сэр.
Ну тогда нужно применить это же самое правил на самих, менеджеров высшего звена:
Почему менеджеры высшего звена не адаптируются к своему стратегическому ресурсу (что не приводит к повышению эффективности работы этого самого стратегического ресурса — людей) для повышения эффективности его работы?
Схлоапываем все 4 пункта, по аналогии — вывод: не хотят!
Батенька, вы не в нефтянке менеджером случайно работаете, чтобы так транжирить ресурсы?