id: Гость   вход   регистрация
текущее время 17:52 28/03/2024
создать
просмотр
ссылки

Чем лучше сжимать диски TrueCrypt под Linux и Windows ?


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


 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Комментарии
— Гость (31/03/2015 03:35, исправлен 31/03/2015 03:39)   <#>

Здесь можно писать, не одевая китель с погонами?



У меня с комбинаторикой всегда было туго; думал, что мне это никогда не понадобится. Ошибся. По-моему, перестановка m элементов множества имеет мощность m!, а из-за того, что речь идёт о битах, и часть элементов (а потому и их перестановок) совпадает, получается 2m. В общем случае (строки k всевозможных элементов длиной m) — это сочетания/размещения. Cnk туда же относятся.



Хотел сразу написать острее, но предупредительно решил, что сам могу ошибаться, мало ли что там, я те работы так и не осилил пока.



Э, это как? Вообще вся идея рушится? Но вы же ниже пишете о чём-то, продолжаете, или то немного о другом?



На данном этапе меня это нисколько не пугает. Пусть хоть в миллиард раз. Если можно показать, что теоретически задача строго разрешима хотя бы с какими-то параметрами — это уже конструктивный шаг.



Хорошо. Меня больше интересуют как раз случайные гаммы.



Когда такая модель не опирается на решение проблем, неограниченная вычислительная стойкость которых считается недоказанно стойкой, то говорят о безусловной модели безопасности.

Выделенное «не» лишнее? Если нет, то я вообще это тройное «не» не могу распарсить.


Информационно-теоретические протоколы и алгоритмы являются стойкими к созданию квантовых или каких-либо иных гипотетических компьютеров с потенциально неограниченными вычислительными возможностями

It is well known that classical computationally-secure cryptosystems may be susceptible to quantum attacks, i.e., attacks by adversaries able to process quantum information. ... we review an argument which shows that a similar problem can arise even if a cryptosystem provides information-theoretic security. As long as its security analysis is carried out within classical information theory, attacks by quantum adversaries cannot in general be excluded.

Unknown vs Renner. Кто кого?



Это радует.



Для mi=128 бит имеем 65536 MBytes ≈ 65 гигов. Для mi=2048 бит имеем 4096 MBytes ≈ 4 гига. Там действительно именно обратно пропорциональная, а не прямая линейная зависимость от mi?



Алиса и Боб предварительно расшаривают общий секретный ключ на 256 бит, перегоняют друг другу 65GB данных, и всё это только для того, чтобы потом доказуемо стойко передать 1MB сообщения? Да, печально.



Извиняюсь за банальный и глупый вопрос, но вроде как размер поXORиваемых элементов разный. Это нормально? Или k расширяется дублированием до размера IT-secure-AONT(R)?



   Новый эвфемизм: «NDA-задача». ☺ Там новизны и ярких концептов хоть отбавляй, попробуй вот докажи что это безопасно — в этом вся загвоздка. Идея примнения AONT'а вместо экстракторов — интересная идея. Может быть, она даже всё упростит. На это стоит посмотреть...
   Я только так и не понял, какими свойствами обладает AONT. Могли бы вы их кратко изложить? AONT сам по себе требует ключа или нет? Это просто бесключевое преобразование текста сообщения в «нековкий» формат? Если да, то достижима ли там идеальная нековкость/непластичность? Можно ли сообщение преобразовать AONT'ом в такой формат, что изменение одного бита в этом формате полностью убивает возможность восстановления «зашифрованного» сообщения? («Шифрование» взято в кавычки, т.к., скорей всего, оно тут бесключевое.) Мне кажется это нереальным... ведь легко проверить, что получим, попрядку флипнув каждый бит в тексте, который результат AONT-преобразования... Или именно оттуда и идёт экспоненциальный рост длины результата AONT-преобразования, что проверять по одному биту будет не проще, чем брутфорсить оригинальное сообщение? Тогда для шифрования текста длиной 128 бит надо переслать AONT-текст длиной 2128 бит? В общем, ЯННП.
   Может быть, мы всё это уже обсуждали ранее, но я этот тред сейчас повторно не перечитывал, так что сразу извиняюсь за повторное спрашивание одного и того же, будь такое случилось. Идея AONT'а тесно связана с ERF, насколько я помню, но по ERF (и вообще по seeded-экстракторам) было много работ, где люди бились за те или иные параметры производительности [хотя какие-то теоретические пределы, кажется, были озвучены (не помню, откуда у меня такая информация, но вроде с каких-то слайдов типа Vidick'овских)]. В общем, ERF (и, вообще, exposure-resilience) — это далеко не так просто, как мне показалось.

— SATtva (31/03/2015 08:26)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
[offtopic, grammarnazi grammarmilitant]
Вещь надевают, человека одевают (если вы не рептилоид, надевающий человека). ☺
[/offtopic, grammarmilitant]
— unknown (31/03/2015 09:47, исправлен 31/03/2015 11:21)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Не в кителе дело.



Я не помню, что держал в уме. Сокращённое множество перестановок: сгенерировать m случайных чисел в диапазоне 0 … m, затем последовательно сделать m циклических битовых сдвигов. Преобразования Swap or Not на одноразовом материале — тоже, если и не идеальный шифр, то там можно как-то точно посчитать все зазоры и доказать, что сокращённого метода анализа нет. Хорошо, что я ракеты не считаю.



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



У меня было придумано несколько вариантов, в т.ч. и такой, но если взять блоки R0kR1k, то можно вычислить R0R1, что вообще-то — утечка и не годится, но я рабочие варианты «какой функций испортить гамму коротким ключом» даже не записывал.



Не требует. Его можно присобачить поверх, поксорив любой его кусочек с рэндомом.



Да.



Возможно, там даже какие-то более сильные термины вводятся для этого случая.



Именно ради этого AONT и был придуман. Кроме как перебором всех битов сообщение не восстановить.



Естественно.



Не оттуда, IT-AONT — это пороговая схема, разделение секретов, теория кодов.



Вы же не один бит будете портить? Для 128 бит придёться испортить все 128, так что да — смысла не имеет. А вот в 512-битном сообщении уже можно поксорить первые 128-бит с рэндомом или отрезать кусочек размером в 128 бит.

— Гость (01/04/2015 00:20)   <#>
РЛ, а космонавтам китель полагается?
— unknown (01/04/2015 14:09)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Для них главное — скафандр.
— unknown (03/04/2015 10:28, исправлен 03/04/2015 12:47)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Вспомнился заголовок темы. Для любителей перестраховочной криптографии и всяких самопальных протоколов.


Оказывается, существует такая частная разновидность случайного оракула как LOR-оракул:


We say that SKE is Left-or-Right (LOR) secure [2] if

It is known that the counter mode is LOR secure if the underlying block cipher (say, AES) is a pseudorandom permutation [2].

Понятно, кто это придумал:
[2] M. Bellare, A. Desai, E. Jokipii, P. Rogaway: fileA Concrete Security Treatment of Symmetric Encryption. FOCS 1997: pp.394–403 (1997)


Они там вывели отношения эквивалентности между LOR-ATK, ROR-ATK, FTG-ATK, SEM-ATK. LOR — это Left or Right; ROR — Real or Random; FTG — find than guess; SEM — semantic. ATK — атаки подобранным открытым и закрытым текстом.


Атака ЛОР-ом и атака «найди и угадай» — это не только интересно звучит, но и вообще штуки полезные. Особенно против любителей перестраховок в криптографии.


LOR — это когда противник может скормить оракулу пару сообщений одинаковой длины, а оракул возвращает результат их зашифровки или расшифровки одного из них равновероятно наугад. Противник должен угадать — левое или право сообщение вернул оракул.


ROR — это когда противник может скормить оракулу сообщение. Оракул может равновероятно наугад вернуть или результат (рас)шифровки этого сообщения, или результат (рас)шифровки случайного рэндома такой же длины.


Остальное там более сложно и специфично. Это к ответу на вопрос, сжимать ли текст перед шифрованием: в модели дискового шифрования у нас или ROR-security, или нестойкое шифрование. Всякая предварительная псевдорэндомизация (а сжатие не тянет даже на это) — это такие костыли-припарки против плохого ROR. Т.е., или у нас есть полная формализованная безопасность из коробки, или у нас только перестраховки.

— Гость (04/04/2015 21:33)   <#>

Да, этот вариант не исключён. Вы уже проговорились, что чувствуете себя вторым слева, рядом с unknown'ом. ☺ Спасибо за замечание, подправлю потом.


Я тоже. Это был просто наглядный пример, который приводят публике не для того, чтобы они потом всё утрировали, но были более аккуратными в повседневных некритичных расчётах.

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

Всюду применяются почему-то именно экстракторы (начиная с биометрической идентификации и заканчивая QKD), а не AONT, хотя я вот сейчас не вижу сразу, почему AONT там неприменим. Мне пока непонятно, как вообще эти два концепта соотносятся между собой. Является ли один частным случаем другого? И т.д.


Охренеть, у меня не осталось цензурных слов. У нас за такое убивали сразу. Unknown, есть один единственный язык коммуникации между людьми — язык математики. Если вы на лету начинаете преопределять обозначения (чем страдают некоторые её прикладные области), это прямой путь вникуда и в нарушение коммуникации между людьми. И тот факт, что вы возможность подставы в таком нюансе даже не обговорили в своём комментарии, сочтя её очевидной, подтверждает мои подозрения, что всё очень плохо и очень запущено. Это общепринято — так писать в статьях по крипто без каких-либо пояснений?


Вот тогда и не надо поганить конвенции, записали бы:

ƒ(IT-secure-AONT(R),k) | ƒ : {0,1}n×m → {0,1}n

или как-то так, а словами бы поясили, что это чем-то похоже по смыслу на те-то операции.


Тут, похоже, уже я запутался в терминологии. Если оно IT, а не просто безусловное вычислительное, то да, всё так, ибо даже подобрав правильный ответ мы не поймём, правильный ли он. Однако, у меня есть NDA-оракул, который всегда скажет, угадали мы результат или нет, из-за чего любая IT-безопасность сводится до уровня, как минимум, безусловной вычислительной.


А более точные оценки есть, сколько надо испортить? Ровно столько же, больше или меньше? Если больше/меньше, то какая там зависимость? Линейная? Полиномиальная? Логарифмическая?


Можно чуть поподробнее, о чём это? И дайте ссылку на страницу. PDF'ки какие-то нестандартные, не ищется в них этот текст у меня.


Тут наверно, скорее, «найди вместо того, чтобы угадывать» (если вы в цитате не ошиблись), а не «найди и угадай».
— unknown (04/04/2015 23:30)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Я же упоминал, что это Secret sharing, в частности японский IT-AONT — это Шамировская схема наизнанку, а Шамировская схема — это 1979 год и там всё вдоль и поперёк изучено. Из Secret Sharing можно сделать AONT, верно и обратное. Я подозреваю, почему AONT не в тренде, а остальное в тренде — потому что надо защищать всякие частичные утечки ключей. А разделение секретов, особенно IT-стойкое — не нашло особого практического применения. Хотя, дополнения подписи RSA-OAEP — это AONT, есть некоторые распределённые файловые системы и базы данных с шифрованием. Только это всё выч. стойкое.


Да мне плевать, что там у вас было.


Спасибо за откровение.


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


Она уже давно нарушена. Давайте не будем выяснять, кто в этом виноват в который раз уже?


Оговариваю возможность подставы лично вам во всех своих коментариях.


Не учите как мне жить, а?


Трёп в форуме не имеет никакого отношения по уровню ответственности к написанию научных статей. С некоего момента для некоторых участников это можно оговорить особо. В т.ч. для всех анонимов. К сожалению, из-за одного анонима-тролля разговаривать со всеми анонимами серьёзно теперь невозможно. Use at your own risk. Более того, в отличие от готовой статьи, программного продукта или патча, на мои коменты в форуме не распространяется репутационной или какой-либо иной ответственности. Особенно перед (псевдо)анонимами с форума.

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

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


Вообще не знаю ответа на вопрос: если скажем первые 128-бит R заксорить с k, то извлечение экстрактором меньшей гаммы насколько будет стойко против противника, не знающего k, но знающего «испорченную» R. Как это зависит от размера R? Должен ли экстрактор эмулировать нечто вроде неизвестного противнику внутреннего состояния размером с k и зависящего от этого k? Должен ли быть эктрактор какого-то особого вида? Вы понимаете, умалчивание об этом, это даже не подстава, это вылезает большой кусок теории, которую надо разбирать и простым обозначением здесь не отделаться. Вкуривайте всякие resilient exposure, leakage security и вот это всё.

В AONT так должно быть по определению. Может я изначально правильно вам написал? Понимаете? Может нормально взять малый k и поксорить с большим R. Это мысли вслух, идеи по весьма специфической области. Я не знаю и не собираюсь точно выводить ответ и докапываться как там и что. У меня полно своих задач, возможно и более интересных лично для меня, чем ваша.

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


Идеальный побитовый AONT должен обеспечивать равномерную стойкость в каждом бите. Хотите меня ловить на словах — сами ищите пруфы или антипруфы, за точность определений, оценок и пр. отвечать не собираюсь.
— Гость (05/04/2015 01:34)   <#>

Это я понял и не опровергаю.


Казалось бы, и AONT и экстракторы решают вопросы с частичными утечками ключей, чем одна защита рыжее другой? В этом и был вопрос.


Я предполагал (и сейчас считаю так; может, зря), что раз AONT (квази)идеальный, то нам всё равно, какие именно биты в нём будут испорчены: первые 128, последние или выбранные случайно — стойкость будет одинаковой (ну, или не ниже той, которая даётся оценками стойкости AONT для заданного числа испорченных бит). Соответственно, мой вопрос был лишь о количестве бит, которые портим.


Вы только для меня лично пишете? Придут в этот тред лет через 5 люди, заинтересуются, будут читать и тоже не поймут, так что если вы начнёте придержиться позиции «вредить», то вредить вы будете всем.


Я не просил вас сделать этот кусок работы. Я не просил его продумывать. Достаточно было написать в скобочках три слова, что ваша операция XOR — это нифига не XOR, а что-то иное. Вот и всё, единственная претензия. Когда вы пишете плюс, а подразумеваете именно минус (и это не ошибка, не невнимательность, не опечатка), это как раз наплевательское отношение к читателям: и ко мне, и ко всем остальным, кто это будет читать. Вот написали вы, что там именно XOR, а это именно вредительство. Я от вас не ждал подставы в выкладках и подумаю, что там именно XOR. А если именно XOR, то как его увязать со всем остальным? Может быть, длины переменных на самом деле не те? Что подразумевал автор? Как исправлять эту формулу? Исправлять операцию XOR или исправлять величину, с которой делается XOR? Тут десятки вопросов вылазят, и можно невзначай на такие обдумывания потратить лишние часы. И всё это только потому, что вам было лень написать маленькое замечание, по сути — два-три лишних (дополнительных) слова.


Я выше ответил, что имелось в виду. Если что, такие претензии я высказывал всем. И если б Шамир начал нести такую пургу в своих работах, я б и ему сделал аналогичное замечание (более того, подобные инциденты были).


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


Конечно, но незачем сознательной безолаберностью усложнять ему эту работу раскидыванием подводных камней во всех местах.


Ага, но почему-то вы очень горазды требовать этой самой ответственности от других — например, от меня.


Честно? Нет, не понимаю. Вот сейчас вы сказали — и я понял. А, может быть, всё это уже описано в статьях, вы это читали, но не стали вдаваться в такие тонкости в рамках ни к чему не обязывающего комментария. Мне-то откуда знать, что просто и известно, а что, по крайней мере, явно не озвучено. С вас ровно это и требовалось сказать: какой из перечисленных случаев имеет место. Я не страдаю конспирологией, но ваш шаблон уж сильно похож на вот это:

if (не нашлось, что ответить & всё верно); then
объявить_тонким_манипулятором;
while (подставы_нет); do
искать_подставу;
done
fi


Ещё раз вам говорю: поксорить можно битовые строки одинаковой длины. Всех, кто складывает пироги с сапогами называет XOR'ом другую операцию, не оговаривая это явно, надо нещадно бить. Вам это скажет любой математик, и большинство прикладников (даже тех, кто зарамарался в подобном сленге по уши) всё равно с этим согласятся. Каждый вводит сленг, удобный для себя, но при этом проигрывает, разбирая сленг других. В итоге теряют все, всё общество в целом. Я бы коротко сказал, что надо ксорить не k, а расширение (от) k: всего одно лишнее слово, и сразу проблему как рукой сняло. Если вы аккуратен в мелочах, вы постараетесь и в форумных комментариях не допусать по возможности двусмысленностей и некорректностей, а если неаккуратен, то это везде так будет: и в коде и в статьях (в том, что вы делаете официально под своим именем).


Я не выискиваю специально чего-то в ваших словах. Обычное вдумчивое чтение ваших комментариев, экзаменуемое холодным разумом, сразу порождает вопросы. Я эти вопросы и задаю.
— Гость (08/04/2015 07:41)   <#>
Про AONT vs экстракторы:

Возьмём простейший пример: нужно скрыть один бит y. Расширяем его до двух бит: {yz,z}. Если один из них неизвестен, найти y нельзя. По сути это одноразовый блокнот. Получается идеальная пороговая AONT-схема, но в случае, когда атакующий может с какой-то вероятностью угадать как y, так и yz, она не будет самой эффективной.

P.S. В сети появилась новая порция квантовых слайдов по темам, обсуждавшимся в этом и других топиках.
— unknown (08/04/2015 10:06, исправлен 08/04/2015 10:47)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Одноразовый блокнот — это и есть неэффективная пороговая схема разделения секрета, его можно рассматривать и так. Но таким образом можно сделать AONT или для истинного рэндома, или для произвольного сообщения, к которому добавлено нужное количество рэндомных битов. Т.е. вам нужно не просто расширение битов, а расширение с true-рэндомизацией. Настоящий же AONT может работать с любыми сообщениями, даже в которых биты скоррелированы. Там может использоваться рэндомизация если нужна неразличимость одинаковых сообщений, а в каких-то случаях может и не использоваться вообще.


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



XOR с дополнением нулями тогда уж. По дефолту подразумевается именно как «испортить для противника ксором неизвестного ему короткого ключа некий больший кусок известного ему сообщения». Но поскольку непонятно можно ли так вообще делать, то нет смысла формально определять операцию — дополнять ли справа, слева, делать ли повторения, повторять с урезанием, заворачиванием «гармошкой», со счётчиком. Это сырая вообще никак толком не сформулированная идея.

— Гость (08/04/2015 10:39)   <#>
Пока не читал статьи, трудно говорить на тему. Заставлять вас пересказывать статьи — тоже нехорошо. То, что одноразовый блокнот — простейшая схема разделения секрета, я знаю.

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


Рандомизация, как и seeded-экстракторы, думаю, не годятся. Это всё сильно переусложнит, но вряд ли даст профит (строго говоря, всё это очень неочевидно). Если мы шифруем рандомную гамму, а потом придерживаемся принципа full exposure, чем дополнительная рандомность тут поможет? Её секретность гарантировать не получится.


Спасибо. Смысл примерно понятен.


Тут немножко упоминалось, кстати.
— unknown (08/04/2015 11:02)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Мне это ничего не говорит:
Однако, у меня есть NDA-оракул, который всегда скажет, угадали мы результат или нет, из-за чего любая IT-безопасность сводится до уровня, как минимум, безусловной вычислительной.

Откуда эта цитата? Из какого-то NDA-документа? Реннер в кулуарах нашептал? Нечто IT-стойкое (кроме OTP) можно на квантовом компьютере перевести в выч.-стойкое?
— Гость (08/04/2015 12:04)   <#>

   Наверно, по смыслу было так?


   Можно и так сказать. Раз вы все NDA-документы читали, я считаю (возможно, ошибочно), что намёков на то, что мне нужно, вам достаточно.
   Как вы помните, у нас есть оракул, который возвращает ответы вида «угадали / не угдали», а также зашифрованный AONT'ом или ещё чем-нибудь ключ. Противник лишь с очень малой вероятностью может получить все биты AONT-текста с нулевой ошибкой; т.е. более вероятно то, что он в большинстве бит ошибётся (а в каких-то нет). Однако, никакого строго порога на число ошибок здесь нет.
   Мы можем не разгадывать AONT, а напрямую брутфорсить самого оракула. Если ключ, к примеру, 256 бит, за ≈ 2255 запросов к оракулу мы его узнаем. AONT и прочие извраты нужны лишь для того, чтобы мы не узнали его существенно быстрее. Отсюда и следует, что безопасность в этой задаче вычислительная по самой сути её постановки.
   Если вы с помощью OTP зашифруете 256 бит, это шифрование будет информационно-теоретически стойким, а в случае с оракулом — нет, поскольку для любой 256-битной строки у вас есть возможность узнать, такая она или нет. Грубо говоря, имеется внешняя функция, которая на расшифрованную гамму/ключ/пароль возрвщает ответ 1, если она верная, и 0, если неверная. При такой постановке ничего информационно-теоретически стойкого существовать не может в принципе, а противник с неограниченными вычислительными возможностями всегда узнает секрет.
   Если что, во всех последних постах я ни о чём, кроме NDA-задачи, вроде речь не вёл. Т.е. квантовое симметричное крипто и т.п. вопросы (на которые, да, Реннер тоже отвечал) я пока не обсуждаю, и мне пока нечего по ним сказать.


   Нет.
— unknown (08/04/2015 13:36, исправлен 08/04/2015 13:36)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Теперь понял. Я изначально держал в уме NDA-задачу и забыл о ней, но отвлёкся на схему с комбинацией квантового и классического каналов между удалёнными абонентами: допустим Алиса и Боб могут согласовать по квантовой линии не более 256 бит в сутки, когда спутники выстроятся в нужную конфигурацию по орбитам с зеркалами и погода не помешает. А классический канал у них через весь глобус и им не жалко по нему гонять гигабайты.



Тогда для NDA-задачи достаточно OTP. С одной стороны, извраты с гипотетическим AONT-локингом классической информации не нужны. Но это так, только если у вас гамма 256 бит и секрет 256 бит. Тогда я ввёл аналогию с комбинацией каналов, чтобы не раскрывать суть NDA-задачи (по крайней мере, здесь я стараюсь формулировать и утверждения и вопросы так, чтобы не раскрыть задачу, пока она всё ещё NDA). Если нам доступна гамма только 256 бит, а нужно защитить секрет (причём заранее заданный, не рэндомный, а произвольный) хотя бы чуть больше 256-ти бит, тогда можно раздуть секрет в виде IT-AONT и заксорить уже в таком виде в нём 256-бит с гаммой (дополнив нулями и всё такое). Можно ли вместо AONT использовать экстракторы для сохранения в открытом виде гаммы большего размера и отжатия из неё меньшего и что там с чем ксорить — другой вопрос, более сложный. Я только упомянул идею, но даже сейчас не решаюсь её разобрать.


Кстати, ещё вот это меня тоже наводило на какие-то идеи применительно к вашей задаче, но никак не могу вспомнить, на какие.

На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3