Набрел тут на статью по интерфейсам в широком смысле -- тут.
Пару цитат:
(классика)
An abstraction leak exists when it is possible for an implementation to affect the environment in a way that was not agreed upon in the interface.
"All non-trivial abstractions, to some degree, are leaky."
и вот это показалось интересным (раздел The Asymptotic Complexity of Technical Debt):
The majority of technical debt in a project originates from an inappropriate reliance on abstraction leaks, or a reliance on extremely non-specific interface contracts that have difficult to foresee consequences.
Во избежания бесполезного холивара (типа поможет, ага):
Автор использует стандартные термины (интерфейс/реализация/контракт), но даёт им свои определения. Если он это специально — троллинг тончайший и заоблачный, поздравляю.
UPD. И по-хорошему в философию бы перенести. Прикладной ценности с учётом плюсов-минусов — честный ноль.
UPD2. Дочитал. Если это троллинг — повторно снимаю шляпу. Особенно за:
"All non-trivial abstractions, to some degree, are leaky"
+
"... unintended effects from the system leak into the environment in a way that compromises its security"
=>
"Every physical implementation of a cryptosystem is vulnerable to a side-channel attack"
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Вот.
S>Во избежания бесполезного холивара (типа поможет, ага): S>Автор использует стандартные термины (интерфейс/реализация/контракт), но даёт им свои определения. Если он это специально — троллинг тончайший и заоблачный, поздравляю.
Я начал с конца читать , и дочитал до интересных и уже знакомых цитат про "текучесть" абстракции + новый пассаж про технический долг. Это мне показалось интересным, плюс разумные рассуждения про выбор языка в зависимости от изменяемости интерфейсов (или как их видит автор).
S>UPD. И по-хорошему в философию бы перенести. Прикладной ценности с учётом плюсов-минусов — честный ноль.
Я не против, но для философии как-то уж примитивно. Эта статься (ее концовка) -- набор прописных истин, собранных в одном месте.
S>UPD2. Дочитал. Если это троллинг — повторно снимаю шляпу. Особенно за: S>
S>"All non-trivial abstractions, to some degree, are leaky"
S>+
S>"... unintended effects from the system leak into the environment in a way that compromises its security"
S>=>
S>"Every physical implementation of a cryptosystem is vulnerable to a side-channel attack"
Пассаж про безопасность я не стал выносить, ибо знаю что там не все так просто. Но... а где косяк в приведенных выше рассуждениях? Как бэ это известный факт: некий криптоалгоритм -- абстракция, ее реализация ведет к неких побочным нежелательным эффектам, непредусмотренным самим алгоритмом (там была ссылка на теорему Гёделя). Можно рассмотреть чисто программную абстракцию, такую как стек программы, ну и далее со всеми остановками в плане безопасности. Ничего такого в этом фрагменте я не вижу.
Здравствуйте, Sharov, Вы писали:
S>Я начал с конца читать , и дочитал до интересных и уже знакомых цитат про "текучесть" абстракции + новый пассаж про технический долг. Это мне показалось интересным, плюс разумные рассуждения про выбор языка в зависимости от изменяемости интерфейсов (или как их видит автор).
Ну тут как: отдельные фразы / предложения — нестареющая классика, а вот их соединение вместе — или троллинг, или к врачу надо
S>Я не против, но для философии как-то уж примитивно. Эта статься (ее концовка) -- набор прописных истин, собранных в одном месте.
Так философия и есть раздел для высокоинтеллектуальных холиваров, архитектура ПО — чисто прикладной раздел.
S>Пассаж про безопасность я не стал выносить, ибо знаю что там не все так просто.
Там "не все так просто", там абсолютно безграмотное утверждение, построенное на омонимах. Abstraction leak и атака на побочные эффекты aka timing/acoustic/etc leak — эт несколько разные вещи.
Особенно интересно было бы поглядеть на side channel attack для qkd-каналов. Every physical implementation, угу.
Здравствуйте, Sinix, Вы писали:
S>Ну тут как: отдельные фразы / предложения — нестареющая классика, а вот их соединение вместе — или троллинг, или к врачу надо
Давайте разбирать, что конкретно вам не понравилось в тексте. Возможно, вы просто что-то упускаете.
S>>Пассаж про безопасность я не стал выносить, ибо знаю что там не все так просто. S>Там "не все так просто", там абсолютно безграмотное утверждение, построенное на омонимах. Abstraction leak и атака на побочные эффекты aka timing/acoustic/etc leak — эт несколько разные вещи.
Не могу с этим согласиться. У вас есть интерфейс — черный ящик, который на входе получает зашифрованный поток данных, а на выходе отдает расшифрованный поток. Это его единственный контракт — в теории. На практике у него есть реализация, которая работает за определенное время, которое пользователь ящика может пронаблюдать. Это в чистом виде утечка абстракции.
S>Особенно интересно было бы поглядеть на side channel attack для qkd-каналов. Every physical implementation, угу.
QKD-система дистрибуции ключей основана на доказательстве определенной теоремы (формальное доказательство корректности контракта) для определенной математической модели (интерфейса). Может оказаться, что физическая теория, основанная на этой модели, имеет свои границы применимости, и тогда абстракция "потечёт". Кроме того, это доказательство ограничивается безопасной передачей ключа, но не безопасностью процесса передачи, шифрования и дешифровки. Side channel attack может быть возможна, например, на чип, выполняющий дешифровку данных.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Я начал с конца читать , и дочитал до интересных и уже знакомых цитат про "текучесть" абстракции + новый пассаж про технический долг. Это мне показалось интересным, плюс разумные рассуждения про выбор языка в зависимости от изменяемости интерфейсов (или как их видит автор). S>Ну тут как: отдельные фразы / предложения — нестареющая классика, а вот их соединение вместе — или троллинг, или к врачу надо
Не согласен. Есть вольные (творческие) подходы к толкованию тех или иных терминов, но в целом для новичка почитать про роль абстракций неплохо. Множество всяческих примеров и противопоставлений.
На hn даже немного обсудили, никто особо не плевался.
S>>Пассаж про безопасность я не стал выносить, ибо знаю что там не все так просто. S>Там "не все так просто", там абсолютно безграмотное утверждение, построенное на омонимах. Abstraction leak и атака на побочные эффекты aka timing/acoustic/etc leak — эт несколько разные вещи.
Вот очень спорно, ибо для алгоритма сортировки вот это все "timing/acoustic/etc leak" не релевантно, а для криптографических алгоритмов весьма. Можно ли назвать это "abstraction leak" в терминах программы, думаю нет. В терминах окружающего мира(кибер-физические системы) -- да, ибо реализация ведет к компрометации системы.
S>Особенно интересно было бы поглядеть на side channel attack для qkd-каналов. Every physical implementation, угу.
Это ж все пока игрушечное, когда там появяться настоящие квантовые компутеры...
Но даже в этом случае, из вики:
The first attack that claimed to be able to eavesdrop the whole key [51] without leaving any trace was demonstrated in 2010. It was experimentally shown that the single-photon detectors in two commercial devices could be fully remote-controlled using specially tailored bright illumination. In a spree of publications[52][53][54] thereafter, the collaboration between the Norwegian University of Science and Technology in Norway and Max Planck Institute for the Science of Light in Germany, has now demonstrated several methods to successfully eavesdrop on commercial QKD systems based on weaknesses of Avalanche photodiodes (APDs) operating in gated mode. This has sparked research on new approaches to securing communications networks
Здравствуйте, Baudolino, Вы писали:
B>Давайте разбирать, что конкретно вам не понравилось в тексте. Возможно, вы просто что-то упускаете.
Да ладно
Вы сам текст прочитайте, его нельзя всерьёз воспринимать. Там вперемешку трюизмы — там всё ок и перлы типа оценки пространства состояний исходя из размеров иконки
S>>Там "не все так просто", там абсолютно безграмотное утверждение, построенное на омонимах. B>Не могу с этим согласиться. У вас есть интерфейс — черный ящик, который на входе получает зашифрованный поток данных, а на выходе отдает расшифрованный поток. Это его единственный контракт — в теории. На практике у него есть реализация, которая работает за определенное время, которое пользователь ящика может пронаблюдать. Это в чистом виде утечка абстракции.
Нет. Side-effect leak и abstraction leak — омонимы. Т.е. общее слово есть, смысл абсолютно ортогональный.
Abstraction leak — это утечка _сложности_ обусловленная неверно выбранной моделью представления (не интрефейса, это разные вещи).
Side-effect attack — это сбор информации с использованием уязвимостей в физической реализации.
Совмещать эти два понятия в одном утверждении — всё равно, что оценивать характер человека по надетой на нём дублёнке из ласки. Ласковый, ага.
B>Side channel attack может быть возможна, например, на чип, выполняющий дешифровку данных
Ну да, вместо принципиального "мы поломали шифроблокнот" внезапно оказывается, что речь про частные уязвимости в конкретных реализациях.
Здравствуйте, Sharov, Вы писали:
S>Не согласен. Есть вольные (творческие) подходы к толкованию тех или иных терминов, но в целом для новичка почитать про роль абстракций неплохо. Множество всяческих примеров и противопоставлений. S>На hn даже немного обсудили, никто особо не плевался.
Для новичков — только качественный научпоп типа такого
. Ничего лучше не объясняет абстракции, чем пошаговое рассмотрение всей картины снизу вверх и обратно.
Иначе потом придётся потратить кучу времени на заблуждения типа "An interface is the intersection between the system and the environment."
Курица — это посредник между перьями и яйцами, ок.
Не, формально-то оно верно…
S>Вот очень спорно, ибо для алгоритма сортировки вот это все "timing/acoustic/etc leak" не релевантно, а для криптографических алгоритмов весьма. Можно ли назвать это "abstraction leak" в терминах программы, думаю нет. В терминах окружающего мира(кибер-физические системы) -- да, ибо реализация ведет к компрометации системы.
Ну да, как лингвистический парадокс "и там утечка, и там утечка — совпадение!" — ок.
Как попытка вывести утверждения путём применения терминологии из проектирования ПО к реальным физическим процессам — фейл.
Единственное, что отсюда можно вытянуть полезного — переход к обсуждению границ применимости методов научного познания. Но получается этот так же элегантно, как предложение о свидании в исполнении поручика Ржевского. В общем, не надо так делать
S>>Особенно интересно было бы поглядеть на side channel attack для qkd-каналов. Every physical implementation, угу. S>Но даже в этом случае, из вики:
И в итоге утверждение о возможной атаке на every implementation сводится к предположению о наличии частных уязвимостей. Подмена понятий как есть.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Не согласен. Есть вольные (творческие) подходы к толкованию тех или иных терминов, но в целом для новичка почитать про роль абстракций неплохо. Множество всяческих примеров и противопоставлений. S>>На hn даже немного обсудили, никто особо не плевался.
S>Для новичков — только качественный научпоп типа такого
. Ничего лучше не объясняет абстракции, чем пошаговое рассмотрение всей картины снизу вверх и обратно.
Если рассматривать "статьи в интернете" то поверю, ибо не читал. А вот что касается лучшего вообще -- то это Бертран Мейер и его книга.
S>>Вот очень спорно, ибо для алгоритма сортировки вот это все "timing/acoustic/etc leak" не релевантно, а для криптографических алгоритмов весьма. Можно ли назвать это "abstraction leak" в терминах программы, думаю нет. В терминах окружающего мира(кибер-физические системы) -- да, ибо реализация ведет к компрометации системы. S>Ну да, как лингвистический парадокс "и там утечка, и там утечка — совпадение!" — ок. S>Как попытка вывести утверждения путём применения терминологии из проектирования ПО к реальным физическим процессам — фейл.
Он глубоко копнул, ибо здесь не про "проектирование ПО vs реальным физическим процессам". А промблемы между теорией и практикой. Т.е. конкретный пример к тезису об "abstraction leak". Впрочем, не очень удачный и можно было бы проще и понятнее, согласен.
S>>>Особенно интересно было бы поглядеть на side channel attack для qkd-каналов. Every physical implementation, угу. S>>Но даже в этом случае, из вики: S>И в итоге утверждение о возможной атаке на every implementation сводится к предположению о наличии частных уязвимостей. Подмена понятий как есть.
Уже потерял нить к этой части дискуссии, но частные уязвимости существуют для каждой имплементации. Одной для всех не существует (прокладку между рулем и сидением мы не рассматриваем). Что не так?
Здравствуйте, Sinix, Вы писали:
S>Нет. Side-effect leak и abstraction leak — омонимы. Т.е. общее слово есть, смысл абсолютно ортогональный.
S>Abstraction leak — это утечка _сложности_ обусловленная неверно выбранной моделью представления (не интрефейса, это разные вещи). S>Side-effect attack — это сбор информации с использованием уязвимостей в физической реализации.
S>Совмещать эти два понятия в одном утверждении — всё равно, что оценивать характер человека по надетой на нём дублёнке из ласки. Ласковый, ага.
Какое же тут противоречие и омонимы? В случае алгоритма шифрования мы неверно выбрали такую модель представления, как окружающий нас мир, точнее его физические процессы. Еще точнее -- у нас не было выбора. Из-за чего такие штуки как Side-effect attack возможны.
Здравствуйте, Sinix, Вы писали:
B>>Не могу с этим согласиться. У вас есть интерфейс — черный ящик, который на входе получает зашифрованный поток данных, а на выходе отдает расшифрованный поток. Это его единственный контракт — в теории. На практике у него есть реализация, которая работает за определенное время, которое пользователь ящика может пронаблюдать. Это в чистом виде утечка абстракции. S>Нет. Side-effect leak и abstraction leak — омонимы. Т.е. общее слово есть, смысл абсолютно ортогональный.
Давайте назовем их А и Б, чтобы не завязываться на общие слова. Суть идеи автора от этого не меняется, она не основана на такой общности.
S>Abstraction leak — это утечка _сложности_ обусловленная неверно выбранной моделью представления (не интрефейса, это разные вещи).
Вы сами это определение придумали? Если взять первоисточник термина — статью Спольски — или любой другой источник, ни о какой сложности речь обычно не идет. У вас есть физическая система, которая описывается некоторой моделью, опускающей некоторые детали внутреннего представления этой системы. Эта модель — абстракция. Интерфейсы системы — подмножество таких абстракций (потому что существуют абстракции, включающие некоторые особенности реализации). Тезис Спольски состоит в том, что использование абстрактных моделей никак не защищает нас от побочных эффектов, которые существуют всегда. И если это так, то этот тезис может быть эквивалентен тому, что у криптосистем есть побочные эффекты, которые можно использовать для анализа поведения этих систем и последующего взлома.
Предполагалось, что в реальном физическом мире есть одна идеальная криптосистема, надежно хранящая поступающую в нее информацию, — черная дыра, возвращающая ее обратно в виде не поддающегося расшифровке излучения Хокинга. Но, говорят, даже это уже не факт.
, и дочитал до интересных и уже знакомых цитат про "текучесть" абстракции + новый пассаж про технический долг. Это мне показалось интересным, плюс разумные рассуждения про выбор языка в зависимости от изменяемости интерфейсов (или как их видит автор).
). Можно рассмотреть чисто программную абстракцию, такую как стек программы, ну и далее со всеми остановками в плане безопасности. Ничего такого в этом фрагменте я не вижу.
