Re: Отечественная криптография
>> Это тоже не совсем так. Когда я получаю сертификат в УЦ, то >> расписываюсь в его получении. Эта подпись и есть связующее звено между >> реальным бумажным и цифровым миром. > > увы, твоя подпись ничем подобным не является Согласно п. 3 ст. 18 Федерального закона от 06.04.2011 N 63-ФЗ "Об электронной подписи", является. -- With best regards Max Dmitrichenko
Re: Отечественная криптография
On 21.01.2015 20:22, Max Dmitrichenko wrote: 21 января 2015 г., 15:54 пользователь Victor Wagner написал: On Wed, 21 Jan 2015 14:46:06 +0300 Max Dmitrichenko wrote: Вот отличная статья с храбра http://habrahabr.ru/post/248269/ на тему использования каких-нибудь сертифицированных реализаций. Интересно, а на сколько ключи ГОСТа подвержены таким закладкам? Там не столько про "использование сертифицированных реализаций" сколько про "не доверяйте сторонним организациям генерировать вам ключи". Нет, не совсем. Я могу генирировать их и у себя на компе. Но если это делается закрытой софтиной, то будь она хоть трижды сертифицирована, а её разработчик крещён, то бей в зеленый барабан. Собственно, генерируя закрытой софтиной, ты доверяешь её автору генерацию ключей. Впрочем, удостоверяющему центру доверять как раз можно - никто не помешает ему сгенерировать свою собственную ключевую пару и выписать на неё сертификат на ваше имя. Это тоже не совсем так. Когда я получаю сертификат в УЦ, то расписываюсь в его получении. Эта подпись и есть связующее звено между реальным бумажным и цифровым миром. увы, твоя подпись ничем подобным не является То что у ГОСТ 28147 существуют более и менее криптостойкие наборы параметров - это факт. Но вот те параметры, которые приведены в RFC 4357 используются уже много лет и пока никто не взломал. Возможно, что и не взломают. Но поговаривают, что если знать, как они были выбараны, то может открыться и тайная дверь. В этом случае и в ключ закладку ставить не придется ). -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54c09922.7080...@nskes.ru
Re: Отечественная криптография
21 января 2015 г., 15:54 пользователь Victor Wagner написал: > On Wed, 21 Jan 2015 14:46:06 +0300 > Max Dmitrichenko wrote: > > >> Вот отличная статья с храбра http://habrahabr.ru/post/248269/ на тему >> использования каких-нибудь сертифицированных реализаций. Интересно, а >> на сколько ключи ГОСТа подвержены таким закладкам? > > Там не столько про "использование сертифицированных реализаций" сколько > про "не доверяйте сторонним организациям генерировать вам ключи". Нет, не совсем. Я могу генирировать их и у себя на компе. Но если это делается закрытой софтиной, то будь она хоть трижды сертифицирована, а её разработчик крещён, то бей в зеленый барабан. > Впрочем, удостоверяющему центру доверять как раз можно - никто не > помешает ему сгенерировать свою собственную ключевую пару и выписать > на неё сертификат на ваше имя. Это тоже не совсем так. Когда я получаю сертификат в УЦ, то расписываюсь в его получении. Эта подпись и есть связующее звено между реальным бумажным и цифровым миром. > То что у ГОСТ 28147 существуют более и менее криптостойкие наборы > параметров - это факт. Но > вот те параметры, которые приведены в RFC 4357 используются уже много > лет и пока никто не взломал. Возможно, что и не взломают. Но поговаривают, что если знать, как они были выбараны, то может открыться и тайная дверь. В этом случае и в ключ закладку ставить не придется ).
Re: Отечественная криптография
On Wed, 21 Jan 2015 14:46:06 +0300 Max Dmitrichenko wrote: > Вот отличная статья с храбра http://habrahabr.ru/post/248269/ на тему > использования каких-нибудь сертифицированных реализаций. Интересно, а > на сколько ключи ГОСТа подвержены таким закладкам? Там не столько про "использование сертифицированных реализаций" сколько про "не доверяйте сторонним организациям генерировать вам ключи". Впрочем, удостоверяющему центру доверять как раз можно - никто не помешает ему сгенерировать свою собственную ключевую пару и выписать на неё сертификат на ваше имя. То что у ГОСТ 28147 существуют более и менее криптостойкие наборы параметров - это факт. Но вот те параметры, которые приведены в RFC 4357 используются уже много лет и пока никто не взломал. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150121155445.5d51aa11@fafnir
Re: Отечественная криптография
26 декабря 2014 г., 12:04 пользователь Victor Wagner написал: > On Thu, 25 Dec 2014 21:14:03 +0300 > Max Dmitrichenko wrote: > > Для работы с юридически значимой электронной подписью нужно не просто, > чтобы поддерживался алгоритм ГОСТ, нужна сертифицированная ФСБ > реализация (это называется СКЗИ - средство криптографической защиты > информации). Вот отличная статья с храбра http://habrahabr.ru/post/248269/ на тему использования каких-нибудь сертифицированных реализаций. Интересно, а на сколько ключи ГОСТа подвержены таким закладкам? -- With best regards Max Dmitrichenko
Re: Отечественная криптография
26 декабря 2014 г., 16:13 пользователь Victor Wagner написал: > Проблемы возникают если у кого-то секретный ключ помечен как not > exportable и его нельзя вместе с сертификатом выгрузить в PKCS#12 и > проимпортировать куда угодно. Но это чисто российская паранойя. Это исключительно программное ограничение. Говорят, что есть утилиты, которые игнорируют данный флажок. То, что ключ от туда вычитывается - это 100%, по понятным причинам. Исключение составляют носители с СКЗИ на борту, там действительно неизвлекаемость гарантируется.
Re: Отечественная криптография
26 декабря 2014 г., 17:42 пользователь Victor Wagner написал: > Можно. На то есть CAdEX. RFC 5126. Соответственно, можно сгенерировать > такую подпись, в которой будет присутствовать доказательство того, что > она сгенерирована не позже определенного срока, и в момент ее генерации > сертификат не был отозван. Правда, потребуется online взаимодействие с > УЦ и timestamping authority. Да, про CAdeS я читал. Я имею ввиду, что законодательно такой механизм у нас не закреплен, соотв. договориться о его использовании с другой стороной будет трудно, ибо мало кто вообще в этом чего-то понимает. Ну и в суде потом придется привлекать экспертов, а то судья вряд ли захочет знакомиться с Алисой и Бобом ) > А вот IE иметь совершенно не обязательно. Я как-то писал генерилку > заявок на базе CertEnroll в виде GUI-шного скрипта на Tcl/Tk. И видел > разнообразный код, вызвывающий методы CertEnroll из командно-строчных > программ на Visual C. Если ты сам пишешь, то да. А если тебе дают уже готовое и говорят "пользуйся"?
Re: Отечественная криптография
On Fri, 26 Dec 2014 16:27:04 +0300 Max Dmitrichenko wrote: > 26 декабря 2014 г., 16:13 пользователь Victor Wagner > написал: > > При том, что в принципе эта подпись нужна для того, чтобы прийти с > > ней в суд и доказывать на ее основании что что-то там было, или не > > было. > > Нет, не только для этого она нужна. В том числе и для этого. И только для этого - юридически квалифицирвоанная. > > > Если эта подпись имеет сертификат ФСБ, значит экспертная оценка > > компетентными органами уже произведена. > > Как подпись может иметь сертитфикат ФСБ? Это СКЗИ может иметь, да. Но Ну конечно же то, чем выработано подпись. > > Если одна из сторон - государство, то лазеек нет. Но есть другая > лазейка. Доказать, что тот или иной документ был подписан до срока > истечения действия сертификата или до даты отзыва - нельзя. Таким Можно. На то есть CAdEX. RFC 5126. Соответственно, можно сгенерировать такую подпись, в которой будет присутствовать доказательство того, что она сгенерирована не позже определенного срока, и в момент ее генерации сертификат не был отозван. Правда, потребуется online взаимодействие с УЦ и timestamping authority. Но вообще-то проблемы неотрекаемости (non-repudiation) никакой российской специфики не имеют, и поэтому можно спокойно изучать этот вопрос по западной литературе. > > Какие проблемы? Нет никаких проблем. Всех active-x элемент > > certenroll (а тогда еще xenroll) устраивает. Не понимаю чем он вам > > не понравился > > - честная микрософтовская утилита. > > Нужно иметь винду, чтобы ей воспользоваться. А даже на виндовых компах > у меня нет IE... выкручиваюсь IE Tab'ом, конечно, но... А вот IE иметь совершенно не обязательно. Я как-то писал генерилку заявок на базе CertEnroll в виде GUI-шного скрипта на Tcl/Tk. И видел разнообразный код, вызвывающий методы CertEnroll из командно-строчных программ на Visual C. P.S на письма не имеющие Cc: в рассылку, больше отвечать не будю -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141226174202.2a274828@fafnir
Re: Отечественная криптография
On Thu, 25 Dec 2014 21:14:03 +0300 Max Dmitrichenko wrote: > 25 декабря 2014 г., 19:21 пользователь Никита Егоров > написал: > > Имено с отечественной сертификацией дела не имел, поӕтому > > проесните, по какому алгоритму КриптоПРО подписывает документы? > > Какие могут быть альтернативы? Только ГОСТ. Альтернативы есть. Есть ГОСТ Р 34.10-2001 и ГОСТ Р.34.10-2012. В последнем предусмотрены ключи размером 256 бит и 512. Для 256 битных ключей предусмотрено 3 набора параметров (совпадающих для обоих гостов) и 5 их обозначений, для 512-битных - два набора параметров. > Мне кажется, что сейчас придет Vitus Wagner и всё расскажет. Сто лет я > уже не был в d-r, но если я правильно ошибаюсь, он даже в соавторах к > RFC на GOST ) А значит, скорее всего, имеет отношение к разработке Не, в соавторах RFC на ГОСТ меня нет. В соавторах тех RFC, которые представляют собой просто перевод гостов, есть моя жена. А я всего лишь автор той реализации, которая включена в дистрибутив OpenSSL. И то уже с тех пор как я этим занимался, появились неофициальные патчи, написанные другими людьми, реализующие алгоритмы 2012 года. В общем, общий принцип такой: Для работы с юридически значимой электронной подписью нужно не просто, чтобы поддерживался алгоритм ГОСТ, нужна сертифицированная ФСБ реализация (это называется СКЗИ - средство криптографической защиты информации). В сертификаты квалифицированной электронной подписи полагается вписывать расширение, которое содержит название используемого СКЗИ. То есть по хорошему счету сертификат на ключ выдается для использования в определенном программном средстве и никак иначе. Все, естественно, нарушают, но... На рынке существуют минимум три сертифицированных СКЗИ, которые работают в Debian. (возможно больше, но я внимательно этот вопрос не изучал). 1. Magpro CryptoPacket фирмы КриптоКом - модуль gost в OpenSSL делался специально для того, чтобы можно было заменить его на сертифицированную engine MagPro CryptoPacket поменяв одну строчку в конфиге OpenSSL. Но все оказалось не так просто - для того чтобы соответствовать требованиям сертификации, нужно чтобы libcrypto.so и libssl.so тоже были из комплекта Криптопакета и их контрольные суммы соответствовали приведенным в формуляре лицензионного СКЗИ. 2. CryptoPro CSP. Там не стали пытаться вписаться в существюущие инфраструктуры криптобиблиотек Unix, а просто собрали под Unix CSP с его микрософтовским API - пользуйся как хочешь. Хотя какие-то утилиты и по-моему модуль с реализацией TLS для апача у них есть. 3. ЛИРССЛ фирмы LISSI - тоже изделие на базе OpenSSL. На сайте они утверждают что уже сертифицировали алгоритмы 12-года. (у криптопро версия 4.0 уже в стадии публичного бетатестирования, но еще не сертифицирована) Это что касается чисто программных решений. Есть еще Рутокен фирмы Aktiv. Там поставляется PKCS11 модуль, который работает в Linux и приведены инструкции по использованию токена с OpenSSL. Изготовить заявку на сертификат, удовлетворяющую требованиям российского законодательства с помощью OpenSSL вполне можно. Но потребуется немножко повозиться. Во-первых, нужно будет научиться генерировать с помощью OpenSSL заявки, содержащие русские буквы в полях DN. Там это довольно замысловато и по умолчанию не включено. Во-вторых, нужно знать и прописать в конфиг OpenSSL OID-ы для специфически российских сущностей, таких как СНИЛС, ИНН и ОГРН, которые в сертификатах квалифицированной электронной подписи, насколько я знаю, обязательны. Поставляют ли вышеуказанные поставщики сертифицирвоанных решений какие-то инструменты, облегчающие эту задачу, я не в курсе. Я из криптокома ушел уже 4 года назад, и внимательно за развитием продуктов не следил. Вот некоторые выжимки из конфига openssl с одной из моих тестовых машин Утверждать что там все правильно не буду. Заявки, сгенерированные с использованием этого конфига я еще не давал на подпись в настоящие УЦ. По значениям приведенных OID-ов можно нагуглить документы, регламентирующие их использование. [ new_oids ] # Russian pension security number. Numeric string SNILS = 1.2.643.100.3 # Organization number in the state registry (for organizations or individual # businessmen) Numeric string OGRN = 1.2.643.100.1 # Individual insurance number (Numeric String) INN = 1.2.643.3.131.1.1 # cert extension to indicate subject sign tool (value - utf8 string) subjectSignTool=1.2.643.100.111 # sequence of four utf8 strings issuerSignTool=1.2.643.100.112 #POLICY idendentifiers for russian cryptography certification classes # if policy includes oid of more secure class, it shoud include all # identifiers of all less secure classes. I.e KC2 - both KC1 and KC2, # most secure KA1 - all six KC1=1.2.643.100.113.1 KC2=1.2.643.100.113.2 KC3=1.2.643.100.113.3 KB1=1.2.643.100.113.4 KB2=1.2.643.100.113.5 KA1=1.2.643.100.113.6 [ req ] # Default_bits parameter is applicable for RSA only default_bits= 2048 default_keyfile = privkey.pem distinguished_name = rus_dn attributes = req_attributes
Re: Отечественная криптография
25 декабря 2014 г., 19:21 пользователь Никита Егоров написал: > Имено с отечественной сертификацией дела не имел, поӕтому проесните, по > какому алгоритму КриптоПРО подписывает документы? Какие могут быть альтернативы? Только ГОСТ. > В целом весь спектр действий по подписыванию в соотвествии с X509 > осуществляет утилита openssl. Может ли она прикинуться КриптоПро - не > знаю... Тут в добавок ко всей бороде X509 есть некоторое количество потенциальных проблем, связанных с ключевыми носителями. Можно, теоретически и на флешке всё хранить. Но только ссыкотно, ибо такая подпись в соотв. с нашим законом юридически значима. Поэтому применяются всякие eToken'ы, рутокены, джакарты. Некоторые из них, например, вообще имеют встроенный криптопроцессор и хранилище ключей, которое "как бы" гарантирует, что ключ никогда не покинет носитель - если тебе нужно что-то подписать или зашифровать, то ты закачиваешь это прямо в носитель, он шифрует/подписывает и выплёвывает обратно. Почему "как бы"? Потому что мы не знаем, наверняка, что в носителе нет закладки. Короче нюансов много, скондочка эту тему не осилить. Мне кажется, что сейчас придет Vitus Wagner и всё расскажет. Сто лет я уже не был в d-r, но если я правильно ошибаюсь, он даже в соавторах к RFC на GOST ) А значит, скорее всего, имеет отношение к разработке всего этого безобразия ) -- With best regards, Max
Re: Отечественная криптография
Имено с отечественной сертификацией дела не имел, поӕтому проесните, по какому алгоритму КриптоПРО подписывает документы? В целом весь спектр действий по подписыванию в соотвествии с X509 осуществляет утилита openssl. Может ли она прикинуться КриптоПро - не знаю... 25 декабря 2014 г., 18:40 пользователь Max Dmitrichenko написал: > Здравствуйте, коллеги! > > Понадобилось тут связаться с электронной подписью согласно нашего > закона 63-ФЗ. Начал пока разбираться с тем, как это работает под > виндой. Но уже предвкушаю будущий геморрой с Linux вообще и с debian в > частности. Кто-то уже имел опыт с этим? > > Из того, что пока я вижу, у меня шевелятся на затылке уши. > Производители ПО и удостоверяющие центры (УЦ) не иначе как сговорились > и подрывают самые фундаментальные основы криптографии. Получение > сертификата через запросы на сертификат - это на столько не популярная > операция, что у тётенек, отвечающих на звонки в УЦ это вызывает > полнейший ступор, даже если УЦ предоставляет такую возможность > согласно своего регламента. Хотя как вообще поворачивается язык > назвать УЦ контору, которая такой возможности не даёт, я не знаю. > > Пользовательский софт КриптоПро (под оффтопик) из коробки как я понял, > не умеет генерировать запрос на сертификат. Для этого ходовым методом > в сообществе отечественных криптографов являются некие офлайновые > формочки, которые работают в браузере через ActiveX и добываются в > конкретном УЦ. > > Короче вопросы у меня пока такие: > 1) Такая проблема только под оффтопиком или в Linux такая же хрень? > 2) Какие решения существуют под Linux? Поддерживают ли они Debian? > 3) Насколько в этой сфере обеспечена совместимость? Почему-то > учреждение, которое требует от меня подписанный документ, требует, > чтобы подпись была сделана КриптоПро версии 3.6. Это значит, что всё > плохо, или всё же можно взять какой-то более альтернативный софт, > который подпишет документ не хуже? > > -- > С уважением, > Max Dmitrichenko >
Отечественная криптография
Здравствуйте, коллеги! Понадобилось тут связаться с электронной подписью согласно нашего закона 63-ФЗ. Начал пока разбираться с тем, как это работает под виндой. Но уже предвкушаю будущий геморрой с Linux вообще и с debian в частности. Кто-то уже имел опыт с этим? Из того, что пока я вижу, у меня шевелятся на затылке уши. Производители ПО и удостоверяющие центры (УЦ) не иначе как сговорились и подрывают самые фундаментальные основы криптографии. Получение сертификата через запросы на сертификат - это на столько не популярная операция, что у тётенек, отвечающих на звонки в УЦ это вызывает полнейший ступор, даже если УЦ предоставляет такую возможность согласно своего регламента. Хотя как вообще поворачивается язык назвать УЦ контору, которая такой возможности не даёт, я не знаю. Пользовательский софт КриптоПро (под оффтопик) из коробки как я понял, не умеет генерировать запрос на сертификат. Для этого ходовым методом в сообществе отечественных криптографов являются некие офлайновые формочки, которые работают в браузере через ActiveX и добываются в конкретном УЦ. Короче вопросы у меня пока такие: 1) Такая проблема только под оффтопиком или в Linux такая же хрень? 2) Какие решения существуют под Linux? Поддерживают ли они Debian? 3) Насколько в этой сфере обеспечена совместимость? Почему-то учреждение, которое требует от меня подписанный документ, требует, чтобы подпись была сделана КриптоПро версии 3.6. Это значит, что всё плохо, или всё же можно взять какой-то более альтернативный софт, который подпишет документ не хуже? -- С уважением, Max Dmitrichenko
Re: криптография
Dmitry Astapov wrote: "Берешь оригинальное ядро" и "с минимальным кол-вом напильников" входят в острый идейный конфликт ... ops. :-)
Re: криптография
Evening, Wladimir. Wladimir Krawtschunowski <[EMAIL PROTECTED]> 22:14 26/8/2003 wrote: >> VH> cryptoloop вполне реально использовать. >> К слову про cryptoloop. Как с минимальным кол-вом напильников собрать >> cryptoloop под 2.4.21? Что-то у меня лыжи совсем не едут ... И с >> патченьем ядра, и с IV_HACK, и gcc 2.95, и 3.0, и 3.3 - не едут, и все >> тут. Куча "xxx redefined, previous definition here", либо модули >> собираются, но не грузятся из-за того, что в ядре нету символов >> proc_mkdir, proc_rmdir ... >> WK> берёшь оригинально ядро и накладываешь WK> ftp://ftp.kerneli.org/pub/linux/kernel/crypto/v2.4/testing/patch-int-2.4.21.0.gz WK> ftp://ftp.kerneli.org/pub/linux/kernel/crypto/v2.4/testing/loop-jari-2.4.21.0.patch WK> там потом появляються куча всяких чиперов, я рекомендую aes. "Берешь оригинальное ядро" и "с минимальным кол-вом напильников" входят в острый идейный конфликт ... -- Dmitry Astapov //ADEpt GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D
Re: криптография
Dmitry Astapov wrote: Evening, Vlad. Vlad Harchev <[EMAIL PROTECTED]> 16:25 17/8/2003 wrote: VH> cryptoloop вполне реально использовать. К слову про cryptoloop. Как с минимальным кол-вом напильников собрать cryptoloop под 2.4.21? Что-то у меня лыжи совсем не едут ... И с патченьем ядра, и с IV_HACK, и gcc 2.95, и 3.0, и 3.3 - не едут, и все тут. Куча "xxx redefined, previous definition here", либо модули собираются, но не грузятся из-за того, что в ядре нету символов proc_mkdir, proc_rmdir ... берёшь оригинально ядро и накладываешь ftp://ftp.kerneli.org/pub/linux/kernel/crypto/v2.4/testing/patch-int-2.4.21.0.gz ftp://ftp.kerneli.org/pub/linux/kernel/crypto/v2.4/testing/loop-jari-2.4.21.0.patch там потом появляються куча всяких чиперов, я рекомендую aes.
Re: криптография
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 26 Август 2003 17:26, Vlad Harchev написал: > On Tue, Aug 26, 2003 at 11:28:25AM +0300, Dmitry Astapov wrote: > > Evening, Vlad. > > > > Vlad Harchev <[EMAIL PROTECTED]> 16:25 17/8/2003 wrote: > > > > > > VH> cryptoloop вполне реально использовать. > > > > К слову про cryptoloop. Как с минимальным кол-вом напильников собрать > > cryptoloop под 2.4.21? Что-то у меня лыжи совсем не едут ... И с > > патченьем ядра, и с IV_HACK, и gcc 2.95, и 3.0, и 3.3 - не едут, и все > > тут. Куча "xxx redefined, previous definition here", либо модули > > собираются, но не грузятся из-за того, что в ядре нету символов > > proc_mkdir, proc_rmdir ... > > На дебиане cryptoloop не пробовал (а в редхетовых ядрах он уже приложен). берешь ядро с ftp.kernel.org берешь patch-int-2.4.21.x.bz2 накладываешь патч далее CONFIG_BLK_DEV_LOOP=y CONFIG_CRYPTO=y CONFIG_CIPHERS=y CONFIG_CIPHER_TWOFISH=y (или какой хочешь) CONFIG_CRYPTODEV=y CONFIG_CRYPTOLOOP=y # CONFIG_CRYPTOLOOP_ATOMIC is not set CONFIG_CRYPTOLOOP_IV_HACK=y компиляешь util-linux уже патчиные в дебиане а далее из howto losetup -e twofish /dev/loop0 /patch mount .. все работает проверенно но медленно loop-aes гораздно быстрее 30мб/c vs 10mb/s - -- Юркин Евгений -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE/Szzz2+gw+ZrY6bIRAnK6AKC/zDnxuhnQqRxzlw3kkAHyWp5D8ACgzDZH BxtMNKivrUoc9rfM7ZOKpQE= =43no -END PGP SIGNATURE-
Re: криптография
On Tue, Aug 26, 2003 at 11:28:25AM +0300, Dmitry Astapov wrote: > > Evening, Vlad. > > Vlad Harchev <[EMAIL PROTECTED]> 16:25 17/8/2003 wrote: > > > VH> cryptoloop вполне реально использовать. > > К слову про cryptoloop. Как с минимальным кол-вом напильников собрать > cryptoloop под 2.4.21? Что-то у меня лыжи совсем не едут ... И с патченьем > ядра, и с IV_HACK, и gcc 2.95, и 3.0, и 3.3 - не едут, и все тут. Куча "xxx > redefined, previous definition here", либо модули собираются, но не > грузятся из-за того, что в ядре нету символов proc_mkdir, proc_rmdir ... На дебиане cryptoloop не пробовал (а в редхетовых ядрах он уже приложен). -- Best regards, -Vlad
Re: криптография
Evening, Vlad. Vlad Harchev <[EMAIL PROTECTED]> 16:25 17/8/2003 wrote: VH> cryptoloop вполне реально использовать. К слову про cryptoloop. Как с минимальным кол-вом напильников собрать cryptoloop под 2.4.21? Что-то у меня лыжи совсем не едут ... И с патченьем ядра, и с IV_HACK, и gcc 2.95, и 3.0, и 3.3 - не едут, и все тут. Куча "xxx redefined, previous definition here", либо модули собираются, но не грузятся из-за того, что в ядре нету символов proc_mkdir, proc_rmdir ... -- Dmitry Astapov //ADEpt GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D
Re: криптография
On Sun, Aug 17, 2003 at 12:03:21AM +0300, CuPoTKa wrote: Hi, > Здравствуйте! > С днем рождения дебиана ;) > > Возникла необходимость хранить данные на сд, но их нужно шифровать. > Нужно прозрачное шифрование, т.е. без распаковок и без создания еще > одной копии при расшифровке, и процесс должен быть быстрый - сунул сд, > хитро его как-нибудь примаунтил с паролем, и данные видно как обычно. > Естественно на сд должно еще как-то писаться а не только читаться ;) > > Прочитал про CFS и т.п. вроде в общем то что нужно,но оно вроде живет > поверх NFS, непонятно громоздится ли на сдшки или нет. > Может кто что подскажет? cryptoloop вполне реально использовать. Только ядро в линуксе неоптимально сделано - оно будет кэшировать только зашифрованные блоки (при каждом ображении к блоку из кэша он будет заново расшифровываться - что сильно ограничивает скорость чтения для данных которые даже в кэше блоков устройста до 10мб/сек на piii-600 при 100% cpu load.) ЗЫ: кстати, не в курсе ли, в других ОС как с кэшированием шифрованных данных обстоят дела? В частности NT? -- Best regards, -Vlad
криптография
Здравствуйте!
С днем рождения дебиана ;)
Возникла необходимость хранить данные на сд, но их нужно шифровать.
Нужно прозрачное шифрование, т.е. без распаковок и без создания еще
одной копии при расшифровке, и процесс должен быть быстрый - сунул сд,
хитро его как-нибудь примаунтил с паролем, и данные видно как обычно.
Естественно на сд должно еще как-то писаться а не только читаться ;)
Прочитал про CFS и т.п. вроде в общем то что нужно,но оно вроде живет
поверх NFS, непонятно громоздится ли на сдшки или нет.
Может кто что подскажет?
--
___
{~._.~}CuPoTKa
( Y ) [EMAIL PROTECTED]
()~*~() System Administrator
(_)-(_)Media International Group
