Terrarium

Естественно, не рассматриваются "ножки наружу". То есть, это - по сути аналог IP-Core Xilinx, делаем некое криптоядро для использования снаружи, вокруг вешаются всякие модули приема/передачи информации, соответствия неким протоколам, и т.д., т.е. о входах/выходах алгоритма авторы заботиться и не должны. Скорость там тоже на уровне - Вы посмотрите внимательно, там за такт работы схемы реально считаются только 4 бита результата 1 итерации ГОСТа (итого, 8 тактов на итерацию, 256 тактов на зашифрование 64 бит открытого текста, и похоже, еще 8 тактов на обмен состояниями). Мне ISE дает оценку 340 МГц из 500 возможных для Virtex5. Вот не очевидно: как сравнить число LUT и FF ПЛИС c GE ASIC? На практике для ПЛИС получается так: 1. 100 LUT + 200 FF 2. 200 LUT + 100 FF и что из них лучше если тупо VHDL скомпилировать под ASIC? У ПЛИСов фиксировано количество входов LUTов, поэтому для них методы оптимизации совсем другие. Есть - САПР для ПЛИС. Есть - некоторая сторонняя оценка для СБИС китайцами. Надо: сделать свою оценку для СБИС для (возможной, если придется) модификации алгоритма. Софта для СБИС, увы, нет. Поэтому либо пытаться так модифицировать алгоритм, чтобы обойтись сторонними оценками, либо сделать что-то свое. Но синопсиса, ПОВТОРЮСЬ, в свободном доступе нету. Я много чего искал и находил, но это, похоже, слишком узко, чтоб его ломали варез-группы. Число денег, сколько стоит официальный синопсис, не окупит смысла проводимой работы. Что надо: показать, что некоторая модификация ключевой развертки ГОСТа не ухудшит его характеристик по скорости: ну, пусть на 10% медленнее станет, или на 10% больше площади кристалла, но не в разы. И да, речь идет об эффективности алгоритмов. Есть ряд мировых стандартов, в них есть набор рекомендуемых алгоритмов шифрования. Чтобы в них включиться, нужно, помимо требований по стойкости, отвечать требованиям по скорости их реализаций. И тут буквально на каждый такт или GE бороться приходится....

Какой там тестинг?! Китайцы вырезали все, что могли, в том числе положили ключ шифрования как константу на этапе синтеза, что существенно облегчило схему.

Во-первых, в этом абзаце речь шла об универсальных процессорах, то-есть система команд дана нам свыше, и ничего менять нельзя. Но эта характеристика тоже важна, поверьте. Во-вторых, рад бы, но реализация, сами понимаете, авторская, закрытая, исходников нет. Сравнить. Но при том, что сделать реализацию в синопсисе я не могу за отсутствием синопсиса. Реализации на ПЛИСах, хоть и показывают некую среднюю температуру по больнице, но иногда очень сильно лажают. На СБИСах, похоже, можно сделать гораздо лучше. Вариант модификации ГОСТа, например, подразумевает наличие двух различных подстановок - по 4 включения каждой на итерацию. Отсюда, видится, нужно добавление одной подстановки плюс демультиплексор, зависящий от конкретного шага алгоритма. Если эта функция тривиальна - 4 верхних подстановки равны, 4 нижних подстановки равны - ну тут все просто элементарно. Но вот по криптоанализу это не всегда есть хорошо (( Как сравнить 30 LUT-ов и 53 FF-ов c 853 GE? что больше? Повторюсь, нет у меня синопсиса. Был бы (тут молитва к модераторам - пустите на ftp, если у вас валяется!) - сгенерил бы. Пока у меня на ПЛИСах есть ключевая развертка примерно в 700 GE если ключ извне и 160 GE если ключ фиксирован... Площадь не нужна - обычно все меряются именно чистыми GE... Но это и рядом не лежит с 650 GE на всю схему. Т.е. я не могу утверждать, что моя vhdl интерпретация госта идеальна. Можно ведь и на 30 килогейтов написать... Ну и наверное вопрос по ходу: вот у нас висит внешний (для алгоритма) ключ 256 бит. Из него, в зависимости от такта работы алгоритма шифрования, надо выбрать 32-битное слово, а потом, опять же в зависимости от такта, из этого 32-битного слова надо выбрать 4-битное слово, которое, сложив с 4 битами промежуточных результатов Х (и с carry - мы же по модулю 2^32 работаем!) занести в память по адресу, где лежало Х... Так вот, выборка ключевой информации на ПЛИСах как-нибудь кроме мультиплексоров решается? Если ключ фиксированный, САПР генерит ROM нужных размеров, и там это все очень экономично получается. А в случае, когда ключ - это переменная? Я привел ссылку на их работу выше. Более достоверной информации у меня нет. И что это за DFT? Понятно, что не Direct Fourier Transform, но вот дальше гугль заманчиво обширен ))

Ну я тут немножко поковырялся в ПЛИСах для реализации столь скудных по GE алгоритмов... Рассмотрел узел ключевой развертки. Начал с 2800GE, закончил 722... А если ключ фиксированный (что, кстати, нонсенс - компрометация его приводит к отказу всей системы безопасности, зависящей от ключа) вообще 160 с небольшим... Но тут 5-6 входовость LUT-ов служит ограничением по GE - минимизировать не удается. А можно на ПЛИСах как-то синтезировать выборку 32 или 4 битного блока из 256-битного входного сигнала без мультиплексоров? А на АСИКах? А то подозреваю, что автор работы, что рассмотрена выше, имеет ввиду что-то другое... Но не говорит. А на ваш фтп меня пока не пущають :rolleyes:

Это я понимаю, но с не согласен - живых ссылок найти не удалось :( Если знаете - плиз, отпишите в личку... Если дизайн где-нибудь на 300000GE, то да. А когда речь идет о сотнях, тут уже сильно сказывается природа LUT-ов. Ведь по сути, это 32 или 64 бита памяти, которые по 5 или 6 входам (это я применительно к Virtex5) выдают однобитовый результат. А в асике вполне возможно трех или 5-битовые подстановки (хотя ее Xilinx через мультиплексор делает - красота!) эффективно нарисовать. Поэтому сравнить свои поделки с вышеприведенной работой с точностью не плюс/минус километр - увы. Ну для себя на FPGA обычно делаю оптимизацию по площади, финальные "забеги" - с повышенной точностью (хотя тогда дизайн разводится почти сутки до Static Timing Report), а про BRAM уже говорил - или все алгоритмы используют его, или все на LUT-ах. В качестве констрейнов мне наш гуру, пока не уволился, пропагандировал правило - объем заполнения кристалла не выше 70% (дальше синтезатор тупит), частота - 50% от максимально возможной кристалла. По его работам (в-основном, fully pipelined - не знаю русского термина? криптографические схемы, сколько копий удастся затолкать в дизайн, а дальше некая логика анализа результатов перебора), если в них не укладываться, обычно проще было поставить два кристалла рядом, и разбить алгоритм пополам. Хотя перед пенсией ГОСТ он любовно "вылизал" до 450МГц на Virtex5, если не ошибаюсь... Уперся в тепловыделение конкретных закупленных плат. Ну они там "жульничают" вовсю, на самом деле... Так, если посмотрите, то 256 бит ключа берутся "из воздуха" (а я их обычно "защелкиваю" в триггеры), есть еще натяжки с точки зрения "жизненной" а не теоретической реализации. Так, хотя стандарт ничего не говорит о том, что подстановки (8 4-битных) должны быть разные, понятно, что применение одной подстановки к 4-битным блокам по очереди тоже позволяет оптимизировать дизайн, ну и т.д. А я по сути в схемотехнике профан-любитель, но иногда математики-теоретики очень хотят знать, как выглядят те или иные конструкции "в железе". Приходится вспоминать институтские крохи :smile3046:

У меня уже не первый год висит нерешенным вопрос следующего вида: необходимо сравнить вычислительную трудоемкость двух алгоритмов - ну, например, блочного шифрования, хеширования... И если для универсальных процессоров величина cycles per byte - цисло тактов процессора для обработки одного байта исходной информации фактически стала стандартом де-факто в кругу разработчиков подобных схем, то вот с FPGA и ASIC разброд и шатания. Я прекрасно понимаю разработчиков Xilinx и Altera (да и остальных наверное), которые в определенный момент перестали вычислять Gate Equivalent для дизайна. Более того, собственные изыскания на эту тему показали громадный разброс GE в зависимости от того, как именно записать алгоритм в VHDL, расставить промежуточные триггера, использовать ли DSP и т.д. И до сего момента мне, в общем-то, вполне хватало сравнений именно реализаций схем в старой доброй ISE9, в которой GE еще считаются, при некоторых равных предположениях для алгоритмов - либо полностью параллельная схема, либо каждый такт только одну итерацию считаем, все константы реализуем логикой или храним в BRAM, и т.д. Но вот возникла задачка: на конференции CHES 2010 Axel Poschmann, San Ling, and Huaxiong Wang взяли да засунули наш ГОСТ 28147-89 в 650GE с помощью Synopsys DesignCompiler для библиотеки UMC L180 0.18μm, а в 2011 году китайские негодяи предложили ряд атак на него, пользуясь регулярностью ключевой развертки (http://eprint.iacr.org/2011/558). Ну и возникает вопрос, а если эту самую ключевую развертку неким образом модифицировать, насколько "потяжелеет" реализация? Здесь уже синтез FPGA не годится... Вы уж извините, что столь нудно и подробно, но просто проблемка специфическая - моей задачей не ставится разработка реального чипа, а получение "сферической лошади в вакууме", но сравнимой с уже посчитанной для ASIC. Вот и возник вопрос: а есть что-нибудь достаточно доступное (особенно с торрентов, ибо мне нужна только итоговая циферка, хоть транзисторов, хоть GE - начальство явно Synopsys не оплатит, а в торрентах, его, увы, очень мало, даже китайских), в чем бы это можно было посчитать? Вроде простая задача, тем более что в эти 650GE не входят триггеры для хранения ключа (и понятно, почему :rolleyes: ), а вот найти что-то доступное для не сильно продвинутого в ASIC не удалось даже в китайском гугле...

Тоже сообщения набирал? ))) Если правильно понял, ребята хотели просто удвоить пропускную способность, скажем так, центрального роутера, через который ходит вся сеть... Делается примерно так: http://www.samag.ru/cgi-bin/go.pl?q=articles;n=10.2004;a=09 Ключевое слово - включить в ядре bonding, дальше его корректно настроить... Будет кому актуально - пишите...

Для обмена данными с помощью общей памяти используются три функции: CreateFile - собственно создаем начальный handle, который дублируем в другой программе, CreateFileMapping - задаем, какого размера у нас будет общая память MapViewOfFile - создаем "окно", в которое 1-й процесс пишет, 2-й - читает... Поэтому, Вы можете создать большое общее пространство, и, открывая в нем "окна" небольшого размера для записи, записав, уведомлять считывающую программу о готовности очередного окна. Программа-считыватель открывает окно, читает, посылает уведомление пишущей, та закрывает окно, и оперативная память для данного окна освобождается. Поэтому реально выделенный объем будет равен ровно тому объему, который уже записан, но еще не прочитан. Далее, организуется запись "по кругу", когда вы по достижении конца файла начинаете писать в его начало. Если вы читаете быстрее, чем пишете, получится стабильная система. Насчет страниц памяти тоже все верно, для современных интеловских процессоров размер страницы составляет 4 килобайта, на кратную величину и надо ориентироваться... Использование каналов, на мой взгляд, для данной задачи несколько удобнее, потому что вам не нужно заботиться о синхронизации - для случая с потоком, скажем, 1 мегабайт/с это вполне подойдет (если, конечно, приемник успевает "переварить" этот поток с точки зрения вычислительной трудоемкости). Кроме того, для ОС Линукс такой подход вообще стандартен - перенаправить вывод одной программы на ввод другой - например, результат поиска файлов на поиск шаблона имени а потом на программу сортировки. При этом вся буферизация/синхронизация ложится на ОС, и все работает очень эффективно - самому написать без вдумчивого анализа и большого опыта написания многопоточных программ вряд ли получится... Если же потоки горазбо больше - гигабитный Ethernet фильтровать, к примеру, то, как альтернативу, предлагаю рассмотреть возможность использования MPI - ru.wikipedia.org/wiki/MPI - он изначально создавался для больших вычислительных систем с интенсивным обменом данными между различными процессами/узлами кластеров.

Извините, а можно их еще раз перевыложить - файл уже не существует. А то захотелось со своими потугами сравнить...