Скажем, у меня есть зашифрованный файл на iPhone, и каждый раз, когда я хочу его расшифровать, я хочу "нарисовать" символ дешифрования вместо того, чтобы использовать клавиатуру для ее ввода.
Если вы попросите пользователя нарисовать символ для дешифрования файла каждый раз, когда это необходимо (например, каждый раз, когда они запускают ваше приложение), они, вероятно, предпочли бы, чтобы он набрал 20 символов или так пароль на крошечной клавиатуре, и они все равно получат защиту, которую им выдаст пароль на 20 символов (в зависимости от того, насколько сложна форма/символ, который они рисуют).
Символ, который они нарисовали, скорее всего будет одним ударом (например, когда вы поднимаете палец), но может быть очень сложным, так что ему трудно повторить его, даже если они видят, что вы его рисуете в. Как будто каждая подпись человека уникальна и трудно дублировать. На самом деле, это может просто слишком усложнить его, если он должен был предотвратить дублирование, поэтому на данный момент это можно игнорировать, и мы можем предположить, что этот символ не будет замечен кем-то другим, и, следовательно, не имеет значения, можно ли его повторить ими или нет.
Я предполагаю, что реальный вопрос заключается в том, как бы вы последовательно преобразовали один и тот же (разумный) ход в один и тот же ключ (например, значение хэша). Очевидно, что в алгоритме должен быть некоторый порог прощения, поскольку от пользователя нельзя ожидать повторения штриха ровно на 100%.
Использование символа в качестве метода дешифрования добавляет к этой проблеме целое другое измерение. Вы никогда не хотите хранить генерируемое хеш-значение в любом месте в незашифрованном виде, поэтому кто-то может получить доступ к этой части жесткого диска и получить ключ дешифрования без необходимости проходить весь процесс рисования и дешифровать файл вручную. Вы также, скорее всего, не хотите хранить ничего о том, как рисуется форма.
Хорошим примером инсульта, который пользователь может использовать в качестве своего символа дешифрования, является "&". символ. Представьте, что пользователь рисует этот символ на своем iPhone каждый раз, когда им нужно расшифровать файл. Размер символа может быть не одинаковым при каждом его рисовании. Кроме того, вращение символа может быть различным в зависимости от того, как пользователь держит свое устройство. В идеале, в обоих случаях, поскольку символ был нарисован, по отношению к пользовательским штрихам, то же самое, он должен иметь возможность генерировать одно и то же значение хэша и, таким образом, расшифровывать файл.
Я думал, что что-то вроде формы или распознавания символов является аналогичным алгоритмом. Когда пользователь рисует что-то (разумно представляя фигуру), а затем фиксирует его до правильной формы, которая будет иметь одно и то же значение хэша каждый раз, когда он будет нарисован. Однако для чего-то подобного вам, скорее всего, понадобится база данных форм, которую можно нарисовать, и если вы выберете что-то вроде всех букв в алфавите, вы получите только 26 букв. Предполагая, что пользователю нужно всего лишь нарисовать один символ для дешифрования файла, у вас есть крайне небезопасный пароль с 26 возможностями.
Еще одна вещь, о которой я думал, - это разбить символ, который нарисован на крошечные сегменты, а затем запустить распознавание символов. Итак, представьте, что у вас есть 4 символа в базе данных: вертикальная линия, горизонтальная линия и диагональ в обоих направлениях. Теперь, когда пользователь рисует, каждый сегмент распознается как один из них, а затем все они объединены для формирования некоторого значения хэш-функции. Поэтому представьте, что пользователь выбрал в качестве своего символа дешифрования букву нижнего регистра "r". Поэтому они начнут с вертикальной линии вниз, а затем вертикальной линии, а затем диагональной линии вверх и вправо. Одна из проблем с этим методом заключается в том, как вы узнаете, когда разделить ход на отдельные сегменты? Вероятно, вы также захотите учесть, сколько времени занимает каждый отдельный сегмент (например, с шагом в 40 пикселей). Таким образом, если кто-то нарисовал деформированный "r", где горб выходит около дна, он не распознается как один и тот же символ и, следовательно, не будет расшифровывать файл.
Третий метод может делить экран на сетку (пока не уверен, какой размер) и просто увидеть, в каких ячейках выполняется штрих, и используя эти данные для генерации строки.
Любые другие идеи о том, как это можно реализовать? Вы когда-нибудь слышали о чем-то подобном? Существуют ли какие-либо фундаментальные недостатки, которые могут помешать работе такой системы?
Спасибо