Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

24.02.2017

Google
WWW CITForum.ru
С Новым годом!
2001 г

Security Pitfalls in Cryptography

by Bruce Schneier
Cryptography Consultant Counterpane Internet Security, Inc.
e-mail: schneier@counterpane.com
Copyright Counterpane Internet Security, Inc., 2001

Подводные камни безопасности в криптографии.

Перевод статьиВасилий Кондрашов

Журнальные статьи любят описывать криптографические продукты в терминах алгоритмов и длины ключей. Алгоритмы благозвучны: их описание может быть немногословным и их легко сравнивать друг с другом. "128-битные ключи означают высокую степень защиты". "Тройной DES означает высокую степень защиты". "40-битные ключи означают низкий уровень защиты". "2048-битный RSA лучше 1024-битного RSA".

Но в действительности всё не так просто. Более длинные ключи не всегда означают лучшую защиту. Сравним криптографический алгоритм с замком на Вашей входной двери. Большинство дверных замков имеют четыре металлических штифта, каждый из которых может находиться в одном из десяти положений. Ключ устанавливает штифты в особой комбинации. Если ключ установит их все правильно, замок откроется. Таким образом, может быть только 10000 различных ключей и взломщик, готовый испробовать все 10000, обязательно попадёт к Вам в дом. Но улучшенный замок с десятью штифтами, дающий 10 миллиардов возможных ключей, возможно, не сделает Ваше жилище безопаснее. Взломщики не испытывают каждый возможный ключ (атака "в лоб"); большинство даже не настолько хитры, чтобы взломать замок (криптографическая атака на алгоритм). Они разбивают окна, выбивают двери, переодеваются полицейскими или отнимают ключи под дулом пистолета. Одна шайка похитителей предметов искусства обходила домашние системы безопасности, пропиливая стены дома цепной пилой. Лучшие замки не спасут от таких атак.

Сильная криптография значит очень много, когда всё сделано верно, но панацеей она не является. Сосредоточение на криптографических алгоритмах, сопряжённое с игнорированием остальных аспектов безопасности похоже на защиту дома не постройкой забора вокруг него, а установкой огромного столба в надежде, что противник налетит прямо на него. Сообразительный нападающий просто обойдёт алгоритмы.

Counterpane (имеется ввиду Counterpane Internet Security, Inc.) потратила много лет на разработку, анализ и взлом криптографических систем. Пока мы занимаемся исследованием опубликованных алгоритмов и протоколов, большая часть нашей работы состоит в проверке реальных продуктов. Мы разрабатывали и анализировали системы, которые защищают секреты, обеспечивают конфиденциальность и правомочность, способствуют коммерции. Мы работали с программным обеспечением, автономным аппаратным обеспечением и всем, что стоит между ними. Мы взламывали некоторые алгоритмы, но почти всегда находились способы атаки, позволяющие полностью обойти сами алгоритмы. Мы не пытаемся пробовать каждый возможный ключ или даже искать недостатки в алгоритмах. Мы используем ошибки в проектировании, реализации и установке. Иногда мы изобретаем новый способ взлома системы, но, по большей части, мы используем те же старые ошибки, которые разработчики повторяют снова и снова.

Атаки на криптографические модели.

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

Мы часто находим системы, которые "аннулируют гарантию" своей криптографии неправильным использованием последней: не проверяя размеры значений, повторно используя случайные параметры, которые повторно использовать никогда нельзя, и т.д. Алгоритмы шифрования не всегда обеспечивают целостность данных. Протоколы обмена ключами не гарантируют получение обеими сторонами одного и того же ключа. В недавнем исследовательском проекте мы нашли, что некоторые (не все) системы, использующие связанные ключи могут быть взломаны, даже если каждый отдельный ключ безопасен. Безопасность – нечто намного большее, чем простое использование алгоритма и ожидание получить работоспособную систему. Даже хорошие инженеры, известные компании и большие усилия не гарантируют устойчивой реализации; наша работа над алгоритмом шифрования в цифровой сотовой связи в США подтвердила это.

Генераторы случайных чисел – ещё одно место, в котором часто ломаются криптографические системы. Хорошие генераторы случайных чисел сложны в разработке, так как их надёжность часто зависит от особенностей аппаратного и программного обеспечения. Многие из проверенных нами продуктов используют плохие. Криптография может быть сильной, но если генератор случайных чисел выдаёт слабые ключи, то систему взломать гораздо проще. Другие продукты используют надёжные генераторы случайных чисел, но не используют достаточно случайности для обеспечения надёжной криптографии.

Недавно Counterpane опубликовала новый класс атак на генераторы случайных чисел (http://www.counterpane.com/pseudorandom_number.html), основанный на нашей работе над коммерческими моделями. Одна из самых неожиданных находок была в том, что определённые генераторы случайных чисел могут быть надёжными при использовании с одной целью, но ненадёжными для другой; обобщение анализа надёжности опасно.

В результатах другого исследования мы рассматривали взаимодействие между двумя, поодиночке надёжными криптографическими протоколами. Мы показывали, как по заданному надёжному протоколу построить другой надёжный протокол, который взломает первый при использовании с теми же ключами на том же устройстве.

Атаки на реализации.

Многие системы рушились из-за ошибок в реализации. Некоторые системы не убеждаются в уничтожении открытого текста после шифрования. Другие системы используют временные файлы, чтобы защититься от потерь данных, связанных с крахом системы, или виртуальную память, чтобы расширить объём доступной памяти; эти возможности могут случайно оставить открытый текст валяющимся на жёстком диске. В особых случаях операционная система может оставить ключи на жёстком диске. В одном из рассмотренных продуктов использовалось специальное окно для ввода пароля. Пароль оставался в памяти окна даже после его закрытия. И не важно, насколько хороша была криптография продукта, – он был взломан через интерфейс пользователя.

Другие системы терпели поражение от менее явных проблем. Иногда одни и те же данные шифровались двумя разными ключами, одним сильным и одним слабым. Другие системы использовали главные ключи и, затем, одноразовые сеансовые ключи. Мы взломали их с помощью частичной информации о разных ключах. Мы также встречали системы с неадекватными механизмами защиты главных ключей, ошибочно полагающихся на надёжность сеансовых ключей. Жизненно важно перекрыть все возможные пути изучения ключа, а не только самые очевидные.

Системы электронной коммерции часто идут на компромисс в вопросах реализации с целью обеспечения простоты использования. Здесь мы находили скрытые слабые места, появившиеся из-за того, что разработчики не продумывали тщательно влияние этих компромиссов на безопасность. Наверное, проводить согласование счетов раз в день проще, но какой вред может нанести злоумышленник за несколько часов? Возможно ли переполнение механизмов контроля, с целью скрыть личность злоумышленника? Некоторые системы хранят скомпрометированные ключи в рабочих списках (hotlists) – атака на такие списки может быть очень плодотворной. Другие системы могут быть взломаны посредством replay-атак: повторным использованием старых сообщений или их частей с целью обмана различных механизмов.

Системы, которые допускают восстановление ключей в экстренной ситуации, предоставляют ещё одно направление для атаки. Хорошие криптографические системы разрабатываются с таким расчётом, чтобы время жизни ключа было как можно короче. Восстановление ключей зачастую сводит на нет усилия по повышению надёжности, заставляя ключ существовать дольше, чем требуется. Более того, базы данных восстановления ключей являются источниками уязвимостей сами по себе и должны разрабатываться и реализовываться с учётом требований безопасности. В одном из рассмотренных продуктов дефект базы данных восстановления ключей давал преступникам возможность для мошенничества с возможностью свалить всё на законных пользователей.

Атаки на пароли.

Многие системы взламываются из-за того, что полагаются на пароли, созданные пользователями. Предоставленные сами себе, люди не склонны к выбору надёжных паролей. Если заставить их использовать надёжные пароли, то они будут их забывать. Когда пароль становится ключом, то, обычно, проще и быстрее угадать пароль, нежели подобрать ключ – мы встречали доскональные системы, терпевшие на этом пути неудачу. Некоторые интерфейсы пользователя только усугубляют проблему, ограничивая длину пароля восемью символами, преобразовывая всё к нижнему регистру и т.д. Даже идентификационная фраза (многословный вариант пароля) может оказаться ненадёжной: поиск среди фраз из 40 символов обычно гораздо проще поиска среди произвольных ключей длиной 64 бита. Нам также встречались системы восстановления ключей, которые дискредитировали надёжные сеансовые ключи использованием слабых паролей для восстановления ключа.

Атаки на аппаратное обеспечение.

Некоторые системы, в особенности, коммерческие, в вопросах безопасности полагаются на защищённое от несанкционированного доступа аппаратное обеспечение – карточки с микропроцессором (smart card), электронные бумажники, защитные заглушки и т.д. Эти системы могут предполагать, что общедоступные терминальные устройства никогда не попадут не в те руки или "не те руки" не будут обладать достаточными знаниями или оборудованием для атаки на аппаратное обеспечение. Хотя аппаратное обеспечение безопасности и является важным компонентом многих надёжных систем, мы не доверяем системам, надёжность которых базируется исключительно на предположениях о защищённости от несанкционированного доступа. Нам редко встречались работоспособные системы защиты от несанкционированного доступа, а инструменты преодоления такой защиты совершенствуются постоянно. Когда мы разрабатываем системы, использующие элементы защиты от несанкционированного доступа, мы обязательно встраиваем дополнительные механизмы обеспечения безопасности на случай, если система защиты от несанкционированного доступа не сработает.

Хронометрические атаки (timing attack) наделали много шума в прессе в 1995 году: закрытые ключи RSA могут быть восстановлены измерением относительных интервалов времени, затраченных на произведение криптографических операций. Эти атаки были успешно применены к карточкам с микропроцессорами и другим средствам надёжной идентификации, а также к серверам электронной коммерции в Сети. Counterpane, в числе других, обобщила эти методы, включая атаки на системы путём измерения уровня потребления энергии, излучения и других побочных каналов и применила их против многих алгоритмов, как с открытым ключом, так и симметричных, в "надёжных" системах идентификации. Однако мы нашли средства идентификации, вытянуть из которых секретный ключ, наблюдая за побочными каналами, нам не удалось. Связанное с этим направление исследований рассматривало анализ ошибок: преднамеренно спровоцированные ошибки криптографического процессора с целью определения секретных ключей. Эффект от таких атак может быть огромным.

Атаки на модели доверия.

Многие из более интересных наших атак были направлены на модели доверия, лежащие в основе системы: кому или чему доверяет системы, каким образом и до какой степени. Простые системы, такие как программы шифрования содержимого жёстких дисков или продукты для обеспечения секретности телефонных переговоров, обладают простыми моделями доверия. Сложные системы, такие как системы электронной коммерции и многопользовательские системы безопасности электронной почты, имеют сложные (и тонкие) модели доверия. Программа для работы с электронной почтой может использовать невзламываемое шифрование, но пока ключи не подтверждены достоверным источником (или пока такое подтверждение не может быть проверено), система остаётся уязвимой. Некоторые коммерческие системы могут быть взломаны путём сговора продавца и покупателя, или двух разных покупателей. Другие системы делают неявные предположения о инфраструктуре обеспечения безопасности, не заботясь о проверке подлинности этих предположений. Если модель доверия не документирована, инженер может неосознанно изменить её на стадии разработки продукта и, тем самым, скомпрометировать систему обеспечения безопасности.

Многие программные системы делают неверные предположения относительно компьютеров, на которых они запущены, – они предполагают, что компьютер надёжен. Такие программы часто могут быть взломаны "троянскими конями" - программами, которые подсматривают пароли, читают открытые сообщения или обходят систему безопасности иным путём. Системы, работающие через вычислительную сеть, должны предусматривать дефекты систем безопасности, вызываемые сетевыми протоколами. Компьютеры, подключённые к Internet также уязвимы. Криптография может оказаться неуместной, если её можно обойти, воспользовавшись ненадёжностью сети. И не существует программного обеспечения, устойчивого к декомпиляции.

Часто система разрабатывается с расчётом на одну модель доверия, а реализуется с другой. Решения, принятые в процессе разработки могут быть полностью проигнорированы к моменту продажи конечному потребителю. Система, надёжная в случае использования надёжными операторами на компьютерах, находящихся под полным контролем компании, использующей систему, может оказаться ненадёжной, если операторы – временные работники с предельно низким жалованьем, а компьютеры не заслуживают доверия. Хорошие модели доверия работают даже тогда, когда одно из предположений о доверии перестаёт быть верным.

Атаки на пользователей.

Даже если система надёжна при надлежащем обращении, пользователи могут случайно нарушить систему безопасности, особенно, если система спроектирована не очень хорошо. Классический пример – пользователь, дающий свой пароль другим сотрудникам, чтобы они могли решать какие-то вопросы, когда его самого нет на месте. Пользователи могут не докладывать о пропаже карточки доступа, если она потерялась. Они могут невнимательно проверять имя на электронном сертификате. Они могут повторно использовать свои надёжные пароли на других, ненадёжных системах. Они могут не изменить настройки безопасности программного обеспечения, установленные по умолчанию на низкий уровень безопасности. Хорошо спроектированная система не сможет решить всех этих социальных проблем, но поможет избежать многих из них.

Атаки на восстановление после сбоя.

Сильные системы проектируются с таким расчётом, чтобы не дать небольшим проблемам с системой безопасности стать большими. Восстановление ключа к одному файлу не должно давать злоумышленнику возможности читать все файла на жёстком диске. Хакер, разобравший смарт-карту не должен иметь возможности найти пути к взлому других смарт-карт в системе. В многопользовательской системе знание секретов одного не должно компрометировать других.

Многие системы по умолчанию находятся в небезопасном режиме. Если функция системы безопасности не работает, большинство людей просто отключают её и занимаются своими делами. Если система проверки кредитных карточек в реальном времени отключена, придётся воспользоваться менее надёжной "бумажной" системой. Аналогично, порой бывает возможно устроить атаку отката версии (version rollback attack) после того, как она была модернизирована для усовершенствования системы безопасности: требование обратной совместимости позволяет злоумышленнику вынудить использовать старый, менее надёжный протокол.

Другие системы не имеют возможности "на ходу" восстановиться после аварии. Если система безопасности взломана, то пути её исправить нет. Для систем электронной торговли, порой насчитывающих миллионы пользователей, это может оказаться чрезвычайно разрушительным. Такие системы должны быть готовы ответить на атаку и модернизировать систему безопасности, не выключая всю систему. Фраза "и компания сворачивается" - не то, что Вы хотели бы поместить в бизнес-план. Хороший проект системы учитывает действия на случай обнаружения атаки и вырабатывает пути локализации повреждения и восстановления после атаки.

Атаки на криптографию.

Порой продукты имеют изъяны в криптографической системе. Некоторые полагаются на собственные алгоритмы шифрования. Они неизменно оказываются очень слабыми. Counterpane имеет определённые достижения в области взлома известных алгоритмов шифрования, но среди "самодельных" таких достижений гораздо больше. Секретность алгоритма не является большим препятствием для анализа – в любом случае, потребуется лишь несколько дней для инженерного анализа криптографического алгоритма из исполняемого кода. Одна из проанализированных нами систем, стандарт электронной почты S/MIME 2, использовала относительно устойчивую конструкцию, но реализованную со слабым криптографическим алгоритмом. Система шифрования DVD выбрала слабый алгоритм и сделала его ещё слабее.

Мы встречали много других криптографических ошибок: реализации, повторяющие "уникальные" случайные величины, алгоритмы цифровой подписи, недостаточно тщательно проверяющие параметры, хэш-функции, изменённые так, что теряются самые важные их свойства. Мы встречали протоколы, которые использовались не так, как это было предусмотрено разработчиками и протоколы, "оптимизированные", по-видимому, тривиальными способами, что полностью лишило их надёжности.

Предупреждение атак или обнаружение атак.

Большинство криптографических систем зависят от предупреждения как от единственного способа защиты: криптография спасает людей от мошенничества, лжи, злоупотреблений и т.д. Защита никогда не должна быть ограниченной. Сильная система также пытается обнаруживать факты злоупотреблений и ограничивать эффект любых атак. Один из наших фундаментальных принципов проектирования состоит в предположении, что рано или поздно любая система будет успешно атакована, возможно, совершенно неожиданным способом и с совершенно неожиданными результатами. Важно иметь возможность обнаружить такую атаку и затем ограничить её, чтобы быть уверенным, что нанесённый ущерб будет минимальным.

Важнее то, что после обнаружения атаки, система нуждается в восстановлении: генерации новой пары ключей, обновлении протокола с запретом использования старого, удаления из системы дискредитированного узла и т.д. К сожалению, многие системы не собирают достаточно данных для предоставления контрольного следа, или не в состоянии защитить эти данные от изменения. Counterpane провела значительную работу по защите журналов контрольной проверки в системах электронной коммерции, по большей части, в ответ на проекты систем, которые могут быть полностью разрушены в результате успешной атаки. Такие системы должны не только обнаруживать атаки, но и давать убедительные улики для суда и присяжных.

Построение надёжных криптографических систем.

Разработчики систем безопасности занимают то, что прусский генерал Карл фон Клаушвиц (Carl von Clausewitz) назвал "позицией в осаде". Хорошая система безопасности должна защищать от любых возможных атак, пусть даже неизвестных на данный момент. Злоумышленники, с другой стороны, должны найти лишь одну ошибку для того, чтобы система была взломана. И они могут мошенничать, сговариваться, дожидаться, пока развитие технологии предоставит им новые инструменты. Они могут атаковать систему способом, о котором разработчик и не подозревал.

Построение надёжной криптографической системы - из разряда того, что сделать плохо легко, а хорошо – очень трудно. К сожалению, большинство людей не видят разницы. В других областях теории вычислительных систем функциональность служит для того, чтобы отличать хорошее от плохого: хороший алгоритм сжатия работает лучше плохого, плохой архиватор выглядит хуже при сравнительном анализе его возможностей. В криптографии – иначе. Только тот факт, что шифрующая программа работает, не означает, что она надёжна. Так случается с большинством продуктов: кто-то читает "Прикладную криптографию", выбирает алгоритм и протокол, удостоверяется в работоспособности и считает, что дело сделано. Но всё не так просто – функциональность не равноценна качеству и непродолжительное тестирование всегда выявляет дефекты системы безопасности. Слишком много продуктов идут на поводу у моды – они используют надёжную криптографию, сами надёжными не являясь.

Оригинал статьи (In English) http://www.counterpane.com/pitfalls.html.

 

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...