Спасибо за развернутый ответ! Да, вы абсолютно правы: прямой Watch на объект — это каноничный путь, и события по нему действительно идут в обход задержек рейтлимитера.
Мой поинт про аннотации и Forget касался скорее специфического кейса, когда контроллер "залипает" на внешних зависимостях, которые мы не можем вотчить напрямую (например, внешний API или состояние облачного ресурса). В таких случаях пользователи иногда пытаются "пнуть" оператор через обновление аннотаций в самом CR, надеясь на мгновенный ретрай. Но если в этот момент объект уже находится в экспоненциальном бэкоффе из-за предыдущих ошибок связи, Forget в связке с кастомным предикатом на аннотацию мог бы "обнулить" историю неудач.
Хотя, соглашусь, идея с легковесной вспомогательной CR для триггера — это архитектурно гораздо более чистое решение для борьбы с раздуванием кэша, чем манипуляции с внутренним состоянием лимитера. Возьму на заметку для высоконагруженных кластеров. Еще раз спасибо за статью!
Шикарный обзор! Особенно зацепило объяснение того, как мы "обманываем" Гейзенберга, перераспределяя шум между квадратурами.
Я сейчас как раз занимаюсь симуляцией протокола BB84 на Qiskit и постоянно сталкиваюсь с тем, что шум (QBER) — это "палка о двух концах". В классическом BB84 на одиночных фотонах любая попытка Евы подсмотреть за ключом неизбежно коллапсирует волновою функцию и задирает QBER до критических 25% (в теории).
Интересно провести параллель: в статье вы описываете, как сжатие помогает вытащить сигнал из-под дробового шума в LIGO. В квантовой криптографии (особенно в CV-QKD) сжатые состояния позволяют передавать ключ через обычные "шумные" городские линии, где одиночные фотоны просто "тонут".
Как вы считаете, насколько реально в ближайшие 5–10 лет увидеть коммерческие системы квантового распределения ключей, использующие именно частотно-зависимое сжатие для обхода радиационного давления в детекторах? Или для задач QKD стандартного "однобокого" сжатия будет достаточно?
Спасибо за подробный разбор работы с очередями и лимитерами! Особенно ценно упоминание reconcile.TerminalError. До его появления в рантайме часто возникала дилемма: либо возвращать nil, теряя информацию об ошибке в стандартных метриках контроллера, либо забивать логи бесконечными ретраями на заведомо неисправимых ошибках (вроде валидации схемы данных).
Вопрос по поводу ExponentialFailureRateLimiter: на практике при больших кластерах (тысячи объектов) дефолтный потолок в 1000 секунд иногда приводит к тому, что исправление конфига пользователем "подхватывается" слишком поздно, если лимитер уже уперся в кап. Не пробовали ли вы комбинировать его с кастомными предикатами, которые принудительно сбрасывают состояние лимитера для объекта при специфических изменениях в metadata.annotations?
Шикарный кейс использования non-extractable CryptoKey. Удивительно, как много проектов до сих пор хранят ключи в localStorage в виде простых строк, подставляясь под любой XSS-вектор.
Особенно порадовал момент с исправлением bias в rejection sampling для safety numbers — такая дотошность к статистическому распределению (байт < 200) выдает серьезный инженерный подход.
Вопрос к автору по поводу групповых чатов: рассматривали ли вы внедрение протокола MLS (Messaging Layer Security) в будущем? Обертка ключа (key wrapping) для каждого участника через ECDH хороша на малых группах, но при росте N до сотен участников нагрузка на отправителя и объем метаданных в БД начнут расти экспоненциально. Планируете ли оптимизировать это через древовидные структуры ключей?
Отличный ликбез, особенно полезен расчет зависимости длины строки и мощности алфавита. Однако, как исследователь, хочу дополнить картину важным фактором, который часто игнорируют при оценке долгосрочной безопасности — стратегией "Harvest Now, Decrypt Later".
Сегодня злоумышленники могут собирать и хранить зашифрованные базы (особенно те, что защищены быстрыми хешами), даже если не могут вскрыть их прямо сейчас. С учетом прогресса в квантовых вычислениях и ежегодного удешевления классических GPU-кластеров, актуальность пароля может закончиться гораздо раньше, чем прогнозирует чистая математика.
Поэтому переход на Argon2id — это не просто "защита от брутфорса", а критическая необходимость для увеличения "стоимости владения" украденными данными в будущем. Как вы считаете, стоит ли внедрять принудительную перегенерацию хешей с увеличенным cost-фактором при каждом входе пользователя, чтобы хотя бы частично нивелировать рост мощностей атакующих?
Information
Rating
Does not participate
Location
Витебская обл., Беларусь
Registered
Activity
Specialization
Бэкенд разработчик, Специалист по информационной безопасности
Спасибо за развернутый ответ! Да, вы абсолютно правы: прямой
Watchна объект — это каноничный путь, и события по нему действительно идут в обход задержек рейтлимитера.Мой поинт про аннотации и
Forgetкасался скорее специфического кейса, когда контроллер "залипает" на внешних зависимостях, которые мы не можем вотчить напрямую (например, внешний API или состояние облачного ресурса). В таких случаях пользователи иногда пытаются "пнуть" оператор через обновление аннотаций в самом CR, надеясь на мгновенный ретрай. Но если в этот момент объект уже находится в экспоненциальном бэкоффе из-за предыдущих ошибок связи,Forgetв связке с кастомным предикатом на аннотацию мог бы "обнулить" историю неудач.Хотя, соглашусь, идея с легковесной вспомогательной CR для триггера — это архитектурно гораздо более чистое решение для борьбы с раздуванием кэша, чем манипуляции с внутренним состоянием лимитера. Возьму на заметку для высоконагруженных кластеров. Еще раз спасибо за статью!
Шикарный обзор! Особенно зацепило объяснение того, как мы "обманываем" Гейзенберга, перераспределяя шум между квадратурами.
Я сейчас как раз занимаюсь симуляцией протокола BB84 на Qiskit и постоянно сталкиваюсь с тем, что шум (QBER) — это "палка о двух концах". В классическом BB84 на одиночных фотонах любая попытка Евы подсмотреть за ключом неизбежно коллапсирует волновою функцию и задирает QBER до критических 25% (в теории).
Интересно провести параллель: в статье вы описываете, как сжатие помогает вытащить сигнал из-под дробового шума в LIGO. В квантовой криптографии (особенно в CV-QKD) сжатые состояния позволяют передавать ключ через обычные "шумные" городские линии, где одиночные фотоны просто "тонут".
Как вы считаете, насколько реально в ближайшие 5–10 лет увидеть коммерческие системы квантового распределения ключей, использующие именно частотно-зависимое сжатие для обхода радиационного давления в детекторах? Или для задач QKD стандартного "однобокого" сжатия будет достаточно?
Спасибо за подробный разбор работы с очередями и лимитерами! Особенно ценно упоминание
reconcile.TerminalError. До его появления в рантайме часто возникала дилемма: либо возвращатьnil, теряя информацию об ошибке в стандартных метриках контроллера, либо забивать логи бесконечными ретраями на заведомо неисправимых ошибках (вроде валидации схемы данных).Вопрос по поводу
ExponentialFailureRateLimiter: на практике при больших кластерах (тысячи объектов) дефолтный потолок в 1000 секунд иногда приводит к тому, что исправление конфига пользователем "подхватывается" слишком поздно, если лимитер уже уперся в кап. Не пробовали ли вы комбинировать его с кастомными предикатами, которые принудительно сбрасывают состояние лимитера для объекта при специфических изменениях вmetadata.annotations?Шикарный кейс использования
non-extractable CryptoKey. Удивительно, как много проектов до сих пор хранят ключи вlocalStorageв виде простых строк, подставляясь под любой XSS-вектор.Особенно порадовал момент с исправлением bias в
rejection samplingдля safety numbers — такая дотошность к статистическому распределению (байт < 200) выдает серьезный инженерный подход.Вопрос к автору по поводу групповых чатов: рассматривали ли вы внедрение протокола MLS (Messaging Layer Security) в будущем? Обертка ключа (key wrapping) для каждого участника через ECDH хороша на малых группах, но при росте N до сотен участников нагрузка на отправителя и объем метаданных в БД начнут расти экспоненциально. Планируете ли оптимизировать это через древовидные структуры ключей?
Отличный ликбез, особенно полезен расчет зависимости длины строки и мощности алфавита. Однако, как исследователь, хочу дополнить картину важным фактором, который часто игнорируют при оценке долгосрочной безопасности — стратегией "Harvest Now, Decrypt Later".
Сегодня злоумышленники могут собирать и хранить зашифрованные базы (особенно те, что защищены быстрыми хешами), даже если не могут вскрыть их прямо сейчас. С учетом прогресса в квантовых вычислениях и ежегодного удешевления классических GPU-кластеров, актуальность пароля может закончиться гораздо раньше, чем прогнозирует чистая математика.
Поэтому переход на Argon2id — это не просто "защита от брутфорса", а критическая необходимость для увеличения "стоимости владения" украденными данными в будущем. Как вы считаете, стоит ли внедрять принудительную перегенерацию хешей с увеличенным cost-фактором при каждом входе пользователя, чтобы хотя бы частично нивелировать рост мощностей атакующих?