Извините, а можете пояснить для не-Физиков, а в чем проблема с помощью лазерного дальномера изменить одновременно расстояние и скорость? Что сложного в одновременном измерении времени до прихода отраженного сигнала и изменения в его частоте?
Не надо ставить что попало в доверенные сертификаты. Пусть с "отечественным сертификатом" работает только сам прокси. Так сделано, например в рутокен-коннект. В нем сертификат НУЦ вкомпилирован. Поэтому в доверенные его можно не ставить.
Сам прокси должен лезть на сервер с "отечественным сертификатом", а в сторону браузера может торчать любой, главное, чтобы браузер нему доверял. Можете сами себе выписать.
Так как современные браузеры позволяют прописывать проксики для списка URL'ов (так работают все "VPN-плагины"), то можно поставить какой-нибудь ГОСТовый stunnel (Криптопро, например), и перенаправить нужные URL'ы через него.
Ну так теплоизоляция и, возможно, подогрев (хотя они и сами греются). Тут объемы несравнимо больше, чем в автомобиле, так что теплоизолировать можно значительно лучше, т.е. потери будет достаточно скромными. Но я уверен, что умные инженеры все посчитали, а мы просто что-то не учитываем. Например, плотность запасаемой энергии в дизеле кардинально больше, чем у аккумуляторов. Стоимость такого количества аккумуляторов будет сильно выше. Деградация у них постоянная, так что амортизация будет сильно дороже и т.д.
Если исходить из предположения, что представленная схема соответствует реальному устройству, то диод загорается когда питание снимается с микрофонов. А если хочется больше уверенности, то можно отдать колонку на СП, чтобы специально обученные ребята ее рентгеном поглядели :)
>Вы понимаете, сколько времени занимает такой виток?
Ну я так и написал, что "будет занимать целую тьму времени"
>А подбросив груз вверх вертикально, у нас не будет этой стабильности, и точность по времени должна быть на уровне доли секунды (причем скорее всего — микросекунды, потому что 1 с — это уже промах в 8 километров).
Ну тоже, можно потратить топлива и зависнуть в верхней точке совершив любые коррекции. Обычное висение на двигателе, как у Маска. Просто время будет стоить дорого, двигатель нужен такой, чтобы 1g создать и т.д.
Еще раз подчеркну: я полностью согласен, что идея бесконечно далека от практики :)
Я не пытаюсь защищать автора, но если мы не ограничены во времени и у нас есть двигатели, то нет необходимости попадать в конструкцию на первом же витке. Можно выйти на примерно необходимую орбиту и постепенно ее корректировать, медленно но верно приближаясь к точке рандеву. Думаю, что на коррекцию потратить можно сильно меньше, чем на полноценное торможение. Каждый виток высокоэллиптической орбиты будет занимать целую тьму времени. А попадать с луны в нужную точку и время системой без обратной связи - это конечно фантастика. Я же правильно понял, что автор хочет с луны выйти на высокоэллиптическую орбиту земли и с это орбиты в перигее ловить груз своей конструкцией?
мощность алфавита и сложность языка просто снижают/повышают первоначальную эффективность кодирования информации данным языком :) Количество информации (энтропии) при этом не меняется. Оптимизация алгоритмов сжатия просто приближает объем выходного файла к объему содержащейся в нем информации.
А я вот согласен с @titbit, что во многих случаях требования к распаковщику и упаковщику могут быть "весьма специфичными" и многие случаи заслуживают отдельных конкурсов :)
Например:
Любые асимметричные применения: инсталятор может упаковываться долго и при этом жрать все ресурсы билд-сервера/фермы билд-серверов, так как упаковывают его один раз. Распаковывать его будут тысячи клиентов, поэтому хорошо бы ему делать это быстро и с минимальными ресурсами. Сюда же IoT (сервер и микроконтроллеры), g-code для станков и т.д.
тонкие каналы и мощные вычислители: неважно сколько ресурсов требует упаковщик и распаковщик снимков с марсохода (спутниковый интернет на северном полюсе, связь с подводными лодками и т.д.). Канал связи с ним довольно узкий, а вычислительных ресурсов у NASA более чем достаточно. Учитывать при этом объем распаковщика будет не очень логично;
потоковое сжатие на магистральных каналах связи: ресурсы упаковщика/распаковщика условно-безграничные, но должно работать с минимальным latency и максимально параллелиться;
можно рассмотреть эволюцию стоимости вычислительных ресурсов: стоимость 305 гигабайт на SSD примерно 1000р. Как быстро окупится постоянное хранение 305 гигабайт, если это позволит сэкономить 10% интернет трафика (поднять скорость на 10%), при стоимости интернета 500р/мес? А если считать в рамках крупной организации? Можно учесть, что производительность процессоров, количество ядер, объем/скорость оперативки, объем/скорость дисков и т.д. дешевеют не очень равномерно. Например, раньше быстро расла производительность ядра, а теперь растет их количество, т.е. теперь для алгоритмов важнее возможность распараллеливания.
можно также рассмотреть: архивное хранение "холодных" данных; большие объемы сырых, но хорошо структурированных и повторяющихся данных в научных исследованиях; сжатие коротких пакетов/сообщений; гомоморфное сжатие (возможность проводить операции, не распаковывая); сжатие в условиях возможных потерь/искажений кусков данных (учет возможностей и особенностей алгоритмов, обеспечивающих избыточность); интеграцию сжатия с алгоритмами шифрования (сейчас жмут потом шифруют, но есть мнение, что сжатие может рассматриваться как кусок алгоритма шифрования, так как на выходе хорошего компрессора данные статистически приближены к "случайным") и т.д. на сколько хватит фантазии :)
Как минимум, для криптографического ПДСЧ, должно быть сложно по выходным данным понять внутреннее состояние, чтобы предсказать предыдущие/последующие данные. Ваша схема этому критерию не соответствует.
Мне кажется, пост-квантовые алгоритмы все равно не гарантируют секьюрности от MiM атак. Да, эти ключи не взломать потом с помощью квантового компьютера, но QKD дает идеальную защиту передачи.
Вы абсолютно правы. Именно поэтому оно и зовется Provable Unconditional — что можно доказать, что при любом развитии технологий, включая появление бесконечно быстрых вычислителей, это останется невзламываемым.
Правда нужно понимать, что для этого мы не ключи для классики должны передавать, а маски для XOR'а (т.е. по объему данных). А на текущий момент QRK — это медленно. У Кванттелекома — сотни килобайт в секунду и зависит от расстояния (уровня ошибок). Для некоторых применений — достаточно.
Ну мы для них и делали (должны были делать, но не срослось) защиту классического канала. У них девайс впринципе не работает при его отсутствии. Т.е. там нет опции: обменяться чем-то заранее/потом, а работать без классического.
Ну тут несколько иначе, насколько я представляю: вы можете заранее обменяться с Бобом базисами, а потом передавать много сообщений. Более того, вы можете обменяться базисами вообще после передачи. В общем, у QKD много проблем, но это не одна из них.
Год назад делали проект с Кванттелекомом, которые тоже делают QKD. И у них та же самая проблема: без зашифрованного классического канала ничего не работает.
Я тогда написал следующие плюсы QKD: 1. усиление гарантий PFS — Provable Unconditional Security
Если в будущем появятся квантовые-компьютеры, ломающие классический PFS (читай эллиптические кривые), это не приведет к компрометации распределнных ключей.
2. Отсутствие нагрузки на сеансовые секреты.
В классической криптографии в результате процедуры аутентификации мы получаем набор сеансовых ключей, который затем используем для шифрования и имтозащиты. Для каждого ключа есть предельно допустимая нагрузка, которая обусловлена двумя факторами: комбинаторными ограничениями и ограничениями по побочным каналам (ПЭМИН). Это означает, что нельзя бесконечно работать на выработаных сеансовых ключах, их когда-нибудь придется заменить. Для снижения нагрузки на ключ можно применить ФДСЧ (обмен новыми случайными числами) или использовать сильные схемы диверсификации (медленно).
КРК для нас является постоянным источником арифметически независимых ключей, т.е. его можно применять вместо ФДСЧ и сократить количество уровней диверсификации.
3. Снижение объемов потенциальной компрометации.
При любых схемах диверсификации сеансовых секретов ключи нижнего уровня всегда будут между собой арифметически связанными. Даже если мы добавляем энтропию с ФДСЧ, случайные числа передаются через защищенный канал связи. Это значит, что если нарушитель скомпрометирует ключ нижнего уровня и найдет способ вычислить по нему другие ключи нижнего уровня (взлом алгоритма диверсификации), он получит полный контроль над каналом связи.
При использовании КРК все квантовые ключи, поступающие из системы КРК в шифратор являются абсолютно независимыми. Т.е. если нарушитель может вычислять по ключу нижнего уровня другие ключи, то компрометация ключа приведет только к компрометации ключей унаследованных от конкретного квантового ключа.
П/С: не являюсь специалистом в QKD, буду рад, если мне объяснят какие еще преимущества дает QKD.
П/С2: я знаю про существование постквантовой криптографии, решетки, изогении и все такое. Я понимаю, что защититься от квантового компьютера можно и без QKD.
Ну может не для красоты, а могули смоделированные гравитационные волны в виде звуковых представить, возможно со смещением спектра в слышимую область.
Извините, а можете пояснить для не-Физиков, а в чем проблема с помощью лазерного дальномера изменить одновременно расстояние и скорость? Что сложного в одновременном измерении времени до прихода отраженного сигнала и изменения в его частоте?
Не надо ставить что попало в доверенные сертификаты. Пусть с "отечественным сертификатом" работает только сам прокси. Так сделано, например в рутокен-коннект. В нем сертификат НУЦ вкомпилирован. Поэтому в доверенные его можно не ставить.
Сам прокси должен лезть на сервер с "отечественным сертификатом", а в сторону браузера может торчать любой, главное, чтобы браузер нему доверял. Можете сами себе выписать.
Так как современные браузеры позволяют прописывать проксики для списка URL'ов (так работают все "VPN-плагины"), то можно поставить какой-нибудь ГОСТовый stunnel (Криптопро, например), и перенаправить нужные URL'ы через него.
Ну так теплоизоляция и, возможно, подогрев (хотя они и сами греются). Тут объемы несравнимо больше, чем в автомобиле, так что теплоизолировать можно значительно лучше, т.е. потери будет достаточно скромными.
Но я уверен, что умные инженеры все посчитали, а мы просто что-то не учитываем.
Например, плотность запасаемой энергии в дизеле кардинально больше, чем у аккумуляторов. Стоимость такого количества аккумуляторов будет сильно выше. Деградация у них постоянная, так что амортизация будет сильно дороже и т.д.
Если исходить из предположения, что представленная схема соответствует реальному устройству, то диод загорается когда питание снимается с микрофонов. А если хочется больше уверенности, то можно отдать колонку на СП, чтобы специально обученные ребята ее рентгеном поглядели :)
Ну так там триггер для этого стоит.
А кто-то успел скачать до того как скорость упала? Может кто-нибудь поделится? :)
В Эльбрусьях все физуровни у PCIe/LVDS... - это синопсис. Так что те же яйца... :(
>Вы понимаете, сколько времени занимает такой виток?
Ну я так и написал, что "будет занимать целую тьму времени"
>А подбросив груз вверх вертикально, у нас не будет этой стабильности, и точность по времени должна быть на уровне доли секунды (причем скорее всего — микросекунды, потому что 1 с — это уже промах в 8 километров).
Ну тоже, можно потратить топлива и зависнуть в верхней точке совершив любые коррекции. Обычное висение на двигателе, как у Маска. Просто время будет стоить дорого, двигатель нужен такой, чтобы 1g создать и т.д.
Еще раз подчеркну: я полностью согласен, что идея бесконечно далека от практики :)
Я не пытаюсь защищать автора, но если мы не ограничены во времени и у нас есть двигатели, то нет необходимости попадать в конструкцию на первом же витке. Можно выйти на примерно необходимую орбиту и постепенно ее корректировать, медленно но верно приближаясь к точке рандеву. Думаю, что на коррекцию потратить можно сильно меньше, чем на полноценное торможение. Каждый виток высокоэллиптической орбиты будет занимать целую тьму времени. А попадать с луны в нужную точку и время системой без обратной связи - это конечно фантастика.
Я же правильно понял, что автор хочет с луны выйти на высокоэллиптическую орбиту земли и с это орбиты в перигее ловить груз своей конструкцией?
Работа под Эльбрусы есть у нас :) хотя всем понятно, что объем рынка Эльбрусов не сравним с разработкой под ARM/RISC-V и, тем более, x86/x64 и веб.
мощность алфавита и сложность языка просто снижают/повышают первоначальную эффективность кодирования информации данным языком :) Количество информации (энтропии) при этом не меняется. Оптимизация алгоритмов сжатия просто приближает объем выходного файла к объему содержащейся в нем информации.
По этому поводу есть https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_%D0%A8%D0%B5%D0%BD%D0%BD%D0%BE%D0%BD%D0%B0_%D0%BE%D0%B1_%D0%B8%D1%81%D1%82%D0%BE%D1%87%D0%BD%D0%B8%D0%BA%D0%B5_%D1%88%D0%B8%D1%84%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F
А я вот согласен с @titbit, что во многих случаях требования к распаковщику и упаковщику могут быть "весьма специфичными" и многие случаи заслуживают отдельных конкурсов :)
Например:
Любые асимметричные применения: инсталятор может упаковываться долго и при этом жрать все ресурсы билд-сервера/фермы билд-серверов, так как упаковывают его один раз. Распаковывать его будут тысячи клиентов, поэтому хорошо бы ему делать это быстро и с минимальными ресурсами. Сюда же IoT (сервер и микроконтроллеры), g-code для станков и т.д.
тонкие каналы и мощные вычислители: неважно сколько ресурсов требует упаковщик и распаковщик снимков с марсохода (спутниковый интернет на северном полюсе, связь с подводными лодками и т.д.). Канал связи с ним довольно узкий, а вычислительных ресурсов у NASA более чем достаточно. Учитывать при этом объем распаковщика будет не очень логично;
потоковое сжатие на магистральных каналах связи: ресурсы упаковщика/распаковщика условно-безграничные, но должно работать с минимальным latency и максимально параллелиться;
можно рассмотреть эволюцию стоимости вычислительных ресурсов: стоимость 305 гигабайт на SSD примерно 1000р. Как быстро окупится постоянное хранение 305 гигабайт, если это позволит сэкономить 10% интернет трафика (поднять скорость на 10%), при стоимости интернета 500р/мес? А если считать в рамках крупной организации? Можно учесть, что производительность процессоров, количество ядер, объем/скорость оперативки, объем/скорость дисков и т.д. дешевеют не очень равномерно. Например, раньше быстро расла производительность ядра, а теперь растет их количество, т.е. теперь для алгоритмов важнее возможность распараллеливания.
можно также рассмотреть: архивное хранение "холодных" данных; большие объемы сырых, но хорошо структурированных и повторяющихся данных в научных исследованиях; сжатие коротких пакетов/сообщений; гомоморфное сжатие (возможность проводить операции, не распаковывая); сжатие в условиях возможных потерь/искажений кусков данных (учет возможностей и особенностей алгоритмов, обеспечивающих избыточность); интеграцию сжатия с алгоритмами шифрования (сейчас жмут потом шифруют, но есть мнение, что сжатие может рассматриваться как кусок алгоритма шифрования, так как на выходе хорошего компрессора данные статистически приближены к "случайным") и т.д. на сколько хватит фантазии :)
Вы абсолютно правы. Именно поэтому оно и зовется Provable Unconditional — что можно доказать, что при любом развитии технологий, включая появление бесконечно быстрых вычислителей, это останется невзламываемым.
Правда нужно понимать, что для этого мы не ключи для классики должны передавать, а маски для XOR'а (т.е. по объему данных). А на текущий момент QRK — это медленно. У Кванттелекома — сотни килобайт в секунду и зависит от расстояния (уровня ошибок). Для некоторых применений — достаточно.
Год назад делали проект с Кванттелекомом, которые тоже делают QKD. И у них та же самая проблема: без зашифрованного классического канала ничего не работает.
Я тогда написал следующие плюсы QKD:
1. усиление гарантий PFS — Provable Unconditional Security
Если в будущем появятся квантовые-компьютеры, ломающие классический PFS (читай эллиптические кривые), это не приведет к компрометации распределнных ключей.
2. Отсутствие нагрузки на сеансовые секреты.
В классической криптографии в результате процедуры аутентификации мы получаем набор сеансовых ключей, который затем используем для шифрования и имтозащиты. Для каждого ключа есть предельно допустимая нагрузка, которая обусловлена двумя факторами: комбинаторными ограничениями и ограничениями по побочным каналам (ПЭМИН). Это означает, что нельзя бесконечно работать на выработаных сеансовых ключах, их когда-нибудь придется заменить. Для снижения нагрузки на ключ можно применить ФДСЧ (обмен новыми случайными числами) или использовать сильные схемы диверсификации (медленно).
КРК для нас является постоянным источником арифметически независимых ключей, т.е. его можно применять вместо ФДСЧ и сократить количество уровней диверсификации.
3. Снижение объемов потенциальной компрометации.
При любых схемах диверсификации сеансовых секретов ключи нижнего уровня всегда будут между собой арифметически связанными. Даже если мы добавляем энтропию с ФДСЧ, случайные числа передаются через защищенный канал связи. Это значит, что если нарушитель скомпрометирует ключ нижнего уровня и найдет способ вычислить по нему другие ключи нижнего уровня (взлом алгоритма диверсификации), он получит полный контроль над каналом связи.
При использовании КРК все квантовые ключи, поступающие из системы КРК в шифратор являются абсолютно независимыми. Т.е. если нарушитель может вычислять по ключу нижнего уровня другие ключи, то компрометация ключа приведет только к компрометации ключей унаследованных от конкретного квантового ключа.
П/С: не являюсь специалистом в QKD, буду рад, если мне объяснят какие еще преимущества дает QKD.
П/С2: я знаю про существование постквантовой криптографии, решетки, изогении и все такое. Я понимаю, что защититься от квантового компьютера можно и без QKD.