Необходимость шифрования строк в базе данных определялась требованиями задачи. С одной стороны, требовалось скрыть все чувствительные данные. С другой стороны, небольшая, но контролируемая утечка считалась приемлемым компромиссом.
Вы правы. У меня этот вариант быстро отпал по другим причинам (из-за вычислительного оверхеда и огромной сложности реализации), поэтому я не углублялся в поддерживаемые операции. Ошибочно предположил, что сравнение тоже относится к их числу. Сейчас почитал подробнее и понял, что это не так. Похоже, что обходные пути есть, но это именно обходные пути, которые увеличивают и без того безумный оверхед. Этот фрагмент статьи стоит поправить. Спасибо, что обратили внимание.
Ситуация была немного нестандартная: "документ" - было собирательное название сущности, к которой были приаттачены разнообразные сканы, фотографии и прочее. То есть это был не столько "документ" в общем понимании, сколько "одна бизнес-операция" (уж такую выбрали терминологию). Например, "Закупка барахла январе, Китай". А внутри - сканы таможенных и бухгалтерских документов, фотографии барахла при приемке.
Да, когда заранее известно, что объем данных ограничен, то вообще нет смысла в ухищрениях. Можно смело делать сортировку на стороне приложения. Если бы я был уверен, что в моем случае объем данных не станет критическим, то сделал бы точно так же.
В моем случае речь шла про названия различных документов. Все они были достаточно длинные и разнообразные, да и строгость сортировки была не критична. Так что пожертвовать первыми несколькими символами было приемлемо.
Да, вы совершенно правы, публичные сервисы следует использовать с осторожностью (про это написано в проблемах и ограничениях). Особенно для случаев, когда все JPEG-носители лежат в одном месте.
Не совсем так. Задача спрятать данные как раз стоит, но не от профессионального стегоанализа, а для использования в повседневных сценариях: локальное хранение, пересылка через почту, хранение в облаке. FUSE-системы вроде CryFs или gocryptfs отлично подходят для шифрования, но наличие зашифрованных данных видно сразу.
Да, конечно при использовании графических редакторов и онлайн-сервисов не спасет никакая избыточность, если будет поаффекчено сразу все хранилище. Но для личного использования и пересылки файлов через почту или облачные хранилища работать будет.
Необходимость шифрования строк в базе данных определялась требованиями задачи. С одной стороны, требовалось скрыть все чувствительные данные. С другой стороны, небольшая, но контролируемая утечка считалась приемлемым компромиссом.
Вы правы. У меня этот вариант быстро отпал по другим причинам (из-за вычислительного оверхеда и огромной сложности реализации), поэтому я не углублялся в поддерживаемые операции. Ошибочно предположил, что сравнение тоже относится к их числу. Сейчас почитал подробнее и понял, что это не так. Похоже, что обходные пути есть, но это именно обходные пути, которые увеличивают и без того безумный оверхед. Этот фрагмент статьи стоит поправить. Спасибо, что обратили внимание.
Спасибо, я и хотел показать не столько решение, сколько путь к нему.
Да, тут имеет смысл остановиться с детализацией, благодарю )
Ситуация была немного нестандартная: "документ" - было собирательное название сущности, к которой были приаттачены разнообразные сканы, фотографии и прочее. То есть это был не столько "документ" в общем понимании, сколько "одна бизнес-операция" (уж такую выбрали терминологию). Например, "Закупка барахла январе, Китай". А внутри - сканы таможенных и бухгалтерских документов, фотографии барахла при приемке.
Да, когда заранее известно, что объем данных ограничен, то вообще нет смысла в ухищрениях. Можно смело делать сортировку на стороне приложения. Если бы я был уверен, что в моем случае объем данных не станет критическим, то сделал бы точно так же.
В моем случае речь шла про названия различных документов. Все они были достаточно длинные и разнообразные, да и строгость сортировки была не критична. Так что пожертвовать первыми несколькими символами было приемлемо.
Да, вы совершенно правы, публичные сервисы следует использовать с осторожностью (про это написано в проблемах и ограничениях). Особенно для случаев, когда все JPEG-носители лежат в одном месте.
Не совсем так. Задача спрятать данные как раз стоит, но не от профессионального стегоанализа, а для использования в повседневных сценариях: локальное хранение, пересылка через почту, хранение в облаке. FUSE-системы вроде CryFs или gocryptfs отлично подходят для шифрования, но наличие зашифрованных данных видно сразу.
Да, лайфхак интересный, спасибо ) Видимо, архиваторы работают но другому принципу: они пропускают весь код, пока не найдут сигнатуру начала архива.
Да, конечно при использовании графических редакторов и онлайн-сервисов не спасет никакая избыточность, если будет поаффекчено сразу все хранилище. Но для личного использования и пересылки файлов через почту или облачные хранилища работать будет.