Ну и ещё CBC перестает работать, и оверхед возрастает, за счет того, что к каждому полю надо прикручивать толстый паддинг и соль.
Думаю, надо сначала ответить на вопрос, что из себя представляет шифрованная база. Я с трудом представляю что-то другое, кроме хранилища вида "логин-блоб", в котором лежит маленькая базочка, которая грузится целиком на клиента и там живет, а потом целиком же отдается обратно. Если же ты хочешь хранить табличку "заболевания" в открытом виде, а шифровать только пары "ид заболевания-ид клиента", то тебе придется делать oblivious transfer, потому что, условно, если клиент запросил название 5-го заболевания - значит оно у него есть.
у меня в дропбоксе лежит эээ 700 статей нечитанных про oblivious transfer, zero-knowledge proofs (interactive & non-interactive), differential security, probabilistic encryption и все такое :/
Софт должен уметь подтягивать интерпретацию любого прошлого способа записи, при сохранении писать "рекомендованным" методом (к вопросу о сроках хранения предыдущих версий... - в т.ч. для старых клиентов, которые вроде как не должны терять доступ к элементам данных)
Периодически пробегать по всем записям: а) проверка существования-доступности б) целостность в) версия способа записи
Про много-приложений-на-платформе - "поднимать требования к дизайну схемы" (читай - все живут в одной верхней онтологии).
Надо сказать, это для меня новое слово в архитектуре, но по всему выходит что клиент должен апгрейдить. Для этого для каждого зашифрованного куска данных должна храниться его версия, очевидно. Или внутри, или рядом.
нуууу вот это да... а вот детали этого процесса нигде не описаны потому что сейчас это очень-очень cutting edge и встречается в основном в научных статьях о криптографии :/
да криптография тут особенно не причём, по-моему. Детали такие же как у нешифрованной базы - номер версии, инкрементальный апгрейд, все дела, просто много раз.
Comments 23
Reply
Reply
Ну и иногда само наличие ячеек палевно (например колво заболеваний у пациента)
Reply
Думаю, надо сначала ответить на вопрос, что из себя представляет шифрованная база. Я с трудом представляю что-то другое, кроме хранилища вида "логин-блоб", в котором лежит маленькая базочка, которая грузится целиком на клиента и там живет, а потом целиком же отдается обратно. Если же ты хочешь хранить табличку "заболевания" в открытом виде, а шифровать только пары "ид заболевания-ид клиента", то тебе придется делать oblivious transfer, потому что, условно, если клиент запросил название 5-го заболевания - значит оно у него есть.
Reply
Reply
Периодически пробегать по всем записям:
а) проверка существования-доступности
б) целостность
в) версия способа записи
Про много-приложений-на-платформе - "поднимать требования к дизайну схемы" (читай - все живут в одной верхней онтологии).
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Leave a comment