Ещё не понял в этом ли проблема, но кажется генерация подписи для JWT через RSA 4096 берет много больше процессора чем когда там была подпись через MD5 - так ли это? Может попробовать 1024 ключи, чтобы снизить нагрузку на CPU во время генерации подписи для JWT(в этом случае короткоживущий от 5 до 15 минут)?
А это сильная разница для CPU ? 1024 vs 4096 условно в единицах процессорного времени. У меня сейчас 50% процессора занято, а при ключе в 1024 будет на сколько меньше?
Я не знаю точно смысла RSA в JWT - так как данные в нем открыты, а подпись используется совсем не для расшифровки данных, а только для проверки "целостности" на случай подделки данных. В таком случае вполне достаточно хэширования. Но пляска с публичным/приватным ключем подразумевается чуть более секюрной, чем один ключ на всех серверах(как в случае с MD5)
Но даже ключ длинною 4к на современных машинах не дает времени подписи в 5 минут. Это происходит за милисекунды. Много времени уйдет на хэширование, если данные большие.
Ну как много. У меня MD5 файла 6 гигабайт с ssd считался 10 секунд. Тут явно уперлись в ssd. Из памяти еще быстрее. + пару милисекунд на шифрование этого хэша.
5-15 минут больше похоже на то, что вы каждый раз генерируете пару ключей заново. Вот на генерацию уходит много времени, да.
GrayHorse, вы мне накидали ссылок, в которых прямым текстом сказано, что hmac реализуется с помощью хэшфункции и криптоалогитма.
Отличием от классической подписи является использование симметричного шифра вместо асимметричного, т.к. валидация третьей стороной тут не нужна, но нужна скорость работы.
А теперь вопрос. Расскажите мне схему проверки подлинности, где шифрование заменено хеширование.
Максим Мосейчук, мы вероятно друг друга не слышим. Данные токена JWT изначально открыты. То есть, нет ни малейшего смысла их шифровать - эти данные в токене публичны. Поэтому, именно хэширования(MD5 + secret) вполне достаточно для проверки его целосности/подлинности. Другое дело, что абсолютное большинство библиотек использует именно асимметричное шифрование для этого токена, скорее больше для удобства.
grabbee, кажется я понял о чем вы. В кообщению подмешивается секретный ключ и это уже все вместе хешируется. Для проверки подлинности этого достаточно, да.