Перейти к содержанию

denyslb

Свой
  • Публикаций

    118
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о denyslb

  • Звание
    Частый гость
  • День рождения 02.08.1980

Контакты

  • Сайт
    http://www.nuclearcat.com/
  • ICQ
    17962627

Информация

  • Город
    Lebanon, Beirut

Старые поля

  • skype
    nuclearcat
  • Facebook
    nuclearcat

Посетители профиля

1 289 просмотров профиля
  1. ads.electronix.ru открывается по http, это поломает вам часть рекламы И т.п.
  2. Вы ссылку админам дайте, чтобы они могли пофиксить.
  3. Вы с этим делом имеете или вам так, поговорить, на уровне "я винду не обновляю и у меня все ок"? Я имею, и с колхозниками которые решили не обновлять софт, ибо "все поломается, легче просто если взломают из бекапа восстановить" - тоже сталкивался, которые бегают кругами и орут "все пропало, спасите помогите". Особенно когда форум проламывают, ждут когда в бекап уйдет проломленная версия, потом с сервера/vm распространяют всякую муть и подделывая учетки других пользователей выклянчивают деньги (а тут много людей с хорошей репутацией и сделки нешуточные заключаются), вдобавку потом форум вышвыривают с хостинга, а админов начинают таскать в органы на допросы. Так что - обновление неизбежно, а старые баги уверен - поправят. Насколько я вижу весь контент сохранился.
  4. Захотелось привести аналогию, более близкую к "железу", про то, как неуместно - "было хорошо, зачем изменили" или "прилепите фичу из старого форума". Жил был старый добрый РАФ-2203 с ЗМЗ-2401, возили водители на нем персонал, привыкли уже к аппарату, но время идет, сам завод выпускающий РАФ закрылся(старую версию не поддерживают), и подрядчики запчасти уже не выпускают(багфиксы связанных плагинов), АИ-76 днем с огнем не найти(новые версии php на хостинге) и по эмиссии РАФ уже не проходит. Да и жрет как не в себя (новый софт обычно лучше оптимизирован). Купило руководство последний форд-транзит. И тут началось: 1)Так, срочно приделайте кривой стартер, раньше было удобно, зимой дернул и поехал. 2)Эта ваша модная светодиодная и жидкокристаллическая панель приборов хайповая фигня (сравнение с вконтакт), фу, срочно принесите и поставьте нам старую панель приборов с РАФа (перенесите старые фичи на новый софт). И т.п. Ну и конечно водителям неудобно, на РАФе чтоб поехать надо было педаль в пол давить, а тут надавил и все плохо закрепленные пассажиры улетели, да и тормоза слишком хорошо работают, пассажиры носом клюют (еще не исправленные баги). Но ничего, обвыкнутся и все будет хорошо.
  5. Это очень странный вопрос. Почитайте, чем чреват взлом и возможные сценарии использования взломанной виртуалки и форума с таким количеством посетителей. Об необходимости обновлять ПО и последствиях отказа от обновлений - должны знать даже рядовые пользователи, уж не говоря о тех, кто вращается в электронных, околоайтишных темах, и тем более IT.
  6. На старый софт никто не будет выпускать security fixes и проводить их аудит. Также меняется серверное ПО, и тот же новый php несовместим со старым форумом. С самим php еще хуже - он монстроидален и дыры в нем находят постоянно, потому держать его свежим - обязательно, как и остальное серверное ПО. Портировать на новый php и фиксы с нового кода форума - очень дорого, по времени, для админов сайта.
  7. @admin спасибо за вашу заботу и новый форум! Уверен, более свежая версия сэкономит немало времени и позволить потратить его на другие идеи. Сам сталкивался, как тяжко состыковывать устаревшие версии форумов с новым софтом на сервере. И с каждой версией php/mysql/gd костыли витиеватее и трудозатратнее.
  8. BLE или пассивный RFID

    А вы думаете 2.4Ghz/BLE/etc не перекрывается рукой и не зависит от угла поворота? Еще как зависит. Еще и будет зависеть от окружающих материалов.
  9. BLE или пассивный RFID

    Инфракрасный светодиод и ограниченное поле зрения у IR приемника? Выйдет еще и очень дешево.
  10. Цитата(jojo @ Dec 4 2017, 14:38) Я может скобки не так расставил. Что, и в этом случае тоже? Идея в том, чтобы использовать часть текущего значения хэша для обращения к заранее вычисленному массиву. На первом проходе массив заполняется хэшами последовательно. intermediate[0] = SHA512(salt+password) intermediate[n] = SHA512(intermediate[n-1]) На втором проходе младшие биты последнего хэша используются как адрес в ранее вычисленном массиве: address0=intermediate[n]&ff.ff hash0=SHA512(intermediate[address0]) address1=hash0&ff.ff hash1=SHA512(intermediate[address1]) и т.д. Примеры того, что вы хотите сделать, я привёл выше. Если как вы написали - intermediate массив заполнен (4 мбайта еще надо суметь заполнить хорошим хешем), то ваша функция скорее тогда дополнение к изначальной, в принципе неплохая идея. Но я подумываю сделать немного по другому, особенность DDR памяти в том, что intermediate[n] вычитывается из памяти очень быстро и возможно кешируется, GDDR5X как раз читает куском в 64 байта, т.е. все равно считается достаточно быстро в GPU. А вот если я сделаю составление аргумента для SHA512 скажем из 1 байта из каждого intermediate элемента... Т.е. например start = intermediate[n]&0xffff i = 0..63 { arg |= intermediate[(start+i)&0xffff][i] << i; (т.е. первый байт аргумента получаем, из первого 64 байт куска, первый байт в нем и т.д.) } и т.д. (возможно есть более аккуратный способ написать это) И писать таким же образом, модифицируя исходный intermediate, по байту, это заодно вымоет все возможные кеши в типичных архитектурах.
  11. Цитата(jojo @ Dec 1 2017, 01:05) Первый проход intermediate[0] = SHA512(salt+password) intermediate[n] = SHA512(intermediate[n-1]) Второй проход = SHA512(intermediate[SHA512(intermediate[0]&ff.ff])&ff.ff]) n раз Примеры scrypt, cryptonight и, конечно, Ethereum. В обоих случаях оптимизации, если мы делаем просто несколько оборотов (как в PBKDF2) мы используем лишь 64*2 байта памяти, чего я стараюсь намеренно избежать. Чем больше памяти использует KDF - тем хуже для запихивания ее перебора в FPGA/GPU и распараллеливания.
  12. Требуется помощь тех, кто соображает в криптографии, т.к. мои познания в теме очень поверхностны. Задача - сделать алгоритм формирования ключа из passphrase, чтобы он не перебирался слишком просто на ASIC/GPU/FPGA (как например PBKDF2). Функция такова: Есть фиксированный salt[X] Есть password первый оборот - intermediate[0] = SHA512(salt+password) intermediate[n] = SHA512(intermediate[0] + ... + intermediate[n-1]) (т.е. хешируем все бОльший и больший блок) Т.е. упор на то, что в последующих оборотах используется материал всех предыдущих(чтобы не параллелили), и к концу обьем используемой памяти растет(чтобы не засунули в ASIC/FPGA с быстрой памятью перебирающий в несколько потоков) Конечное вычисление = последний оборот. Имеет ли право на жизнь такое?
  13. Цитата(Kabdim @ Nov 24 2017, 12:06) Если же с бытовой точки зрения, при упаковывании больших потоков информации нужно добавить key meshing. Но в целом ваш подход без определения модели противника, стоимости информации, объемов инфы, процедуры смены ключей при их компрометации - глубоко неправильный. На таком уровне любой современный алгоритм - достаточно хороший. Если есть возможность лучше возьмите openssl и сделайте не нём, это будет лучше чем писать самому. openssl в stm32, вы пошутили? Кстати именно openssl, даже не в embedded я бы не особо доверял(особенно высокоуровневым фунцкиям, где могут быть сюрпризы типа heartbleed), кроме недостатка в виде безумного API, судя по новостям у него очень плохо в последнее время с верификацией нового кода, я предпочту его форки. Уточню, это брелок для хранения ssh ключей на stm32f103, проект опенсорс. Буду использовать и для своих целей, первую версию - для некритических задач. Основа крипто в брелке у меня на аналоге, mbedtls, который более дружен с embedded. Причем тут key meshing - не совсем понял, у меня создается ключ для AES256 с помощью SHA512, смешивая рандомную строку с паролем, по сути рандомная строка работает как salt, затем этим AES256 дешифруем ключ RSA(до 4096 байт включительно) размером в ~527 байт, хранящийся на внутренней флеше. Насколько я знаю, в данном случае допустим банальный CBC, т.к. ни ciphertext, ни plaintext атакующий ни модифицировать не может, как и перехватить данные и проанализировать, все происходит внутри чипа. А вот украсть брелок и сдернуть прошивку - вполне. Против всяких подслушек по питанию я пока защищаться не буду, т.к. во первых маловероятно, что кто-то воткнет мне такое в комп, чтоб я этого не заметил, и поначалу задачи будет выполнять распространенная платка за $2, а для защиты от атак по питанию и EMI надо разрабатывать плату с нуля. Модель противника - написана выше, уточню - это посторонний человек который может украсть брелок, без огромного финансирования(т.е. кластеры и железки типа 8x1080, электронный микроскоп и т.п. ему наврядли доступны), и задача сохранить ciphertext нерасшифрованным до момента когда доступ на сервера отзовут (обычно сутки-двое). Стоимость информации обычно мала, сама информация существенной стоимости не имеет, а вот возможные деструктивные действия с помощью ключей - уже хуже.
  14. Цитата(esaulenka @ Nov 23 2017, 23:54) Денис, Вы сами подумайте, что и от кого надо защищать. Пока не очень понятно, что у Вас хранится, как передаётся и проч. Предположим, что методом прямого перебора сломать это изделие не получится. Я крипто-дилетант, но искренне уверен, что AES128 достаточно надёжен (т.е. квантовых компьютеров в обозримом будущем не появится; майнеры разумной стоимости за разумное время 128 бит не переберут никак). Т.е., предполагаем, что хакер каким-то образом получил доступ к содержимому памяти контроллера. Осталось малое - подобрать пользовательский пароль (сколько байт?), и всё - искомый plaintext у нас в кармане (мы ведь его прятали?). Насколько это реально, не знаю. Как-то интересовался темой "прочитать залоченный контроллер", но никого, внушающего доверие, не нашёл... Зато слышал много рассказов (и здесь в т.ч.) в духе "друг брата мужа сестры сам так делал...". В plaintext хранится RSA-4096 (точнее длины и сами E,P,Q) в STM32F1. Сам контроллер дешифрует ключ, и подписывает с его помощью данные подсунутые юзером. Несомненно, если плату украдут, через некоторое время(возможно в течении 1-2 часов, уязвимостей в контроллерах хватает) зашифрованные ключи сдернут, но если юзерский пароль достаточной сложный, то перебирать пароль прийдется долго. Задачу можно чуть усложнить, залив плату эпоксидкой, я думаю пока ее уберут - это займет время. Можно еще сложнее - многослойная плата, после программирования отламываем кусок с падами программирования по перфорации, сам чип в BGA корпусе. Еще больше времени выигрываем. SHA512 сам по себе даже на 8x1080 перебирается 8624.7MH/s., можно конечно усложнить и сделать как в PBDKF несколько оборотов, но даже так,к примеру на 1GH/s это около 60 часов на слабенький 8 символьный alphanumeric с разным регистром, а вот если добавить спецсимволы - 83 дня, чего в принципе достаточно, чтобы сообщить о краже и сменить этот RSA ключик. Задача еще усложняется тем, что кроме перебора хеша надо дешифровать кусок данных и проверить его на валидность, это уже надо попотеть, чтоб спараллелить и скрипт-кидди уже не смогут затолкать в какойнить готовенький hashcat. В моем случае предполагается защита от "хакеров" не обладающих значительными ресурсами. Да, кстати квантовые компы ухудшают AES, который является симметричным крипто - лишь на порядок. Это много, но не фатально. А вот RSA с ними станет бесполезен, как и EC. А как ломать STM32F0 и выдергивать из них прошивку, вот реальные данные: https://www.aisec.fraunhofer.de/content/dam...r-obermaier.pdf
  15. разбираюсь с mbedTLS

    Цитата(Ruslan1 @ Nov 3 2017, 20:25) MBEDTLS_ERR_PK_INVALID_PUBKEY поборол. Ошибка в конфиге была: Пытался использовать сертификат с ключом (2048 бит) длинной больше чем указано в MBEDTLS_MPI_MAX_SIZE (задается в байтах). вызовы у функций работы с файлами в FatFS другие, и форматы данных и ключи другие. Чтоб не множить сущности, переписал вызовы прямо в исходниках mbedTLS, благо их не так уж много. Можно, конечно, и перекодирующую фунцию вставить для адаптации, но она не всегда короткая. Новый вопрос: А насколько нужна и актуальна система отзыва сертификатов (CRL) для ембеддед клиента? что с ней делать? Ну вот к примеру каспер когда начинает перехватывать траффик для проверок на вирусы, CRL перестает работать, хотя может уже и пофиксили. Т.е. они не парились этим вопросом. На случай если сертификат сервера скомпрометировали - оставляет возможность проверить то, не отозван ли он.