str4d/rage

Some questions about using

percy507 opened this issue · 6 comments

Hi @str4d,

Thanks for your great project. I have some questions during using rage.

Why it spend almost same time for encrypting 100MB's video or 14KB's text file?

I have use the crate made a test. The time is a second or so.

Does passphrase support non-ASCII characters?

Generally, we use ASCII characters to generate a passphrase. But I am curious if it has potential risk to use non-ASCII characters for a passphrase. I have tested with Chinese, it seems all right.

str4d commented

Why it spend almost same time for encrypting 100MB's video or 14KB's text file?

Hard to know without an example to reproduce your observation with, but it's possible that the asymmetric operations required to encrypt to recipients are the primary cost on your machine.

Does passphrase support non-ASCII characters?

This should work fine. Passphrases are read by parsing a line of input (either from the pinentry binary, or stdin if pinentry isn't available) as a UTF-8 string.

Thanks for your answer. But I am still confused.

but it's possible that the asymmetric operations required to encrypt to recipients are the primary cost on your machine.

I think your guess is right. Before your answer, I think passphrase-encrypted is symmetric.

Does the passphrase-encrypted support symmetric? Or does rage support symmetric encryption?

str4d commented

I think passphrase-encrypted is symmetric.

Aha! If you're encrypting to a passphrase, then it is expected that encryption and decryption takes at least a second, because that is the hardness level we target.

rage/age/src/scrypt.rs

Lines 23 to 26 in 17d1f87

/// Pick an scrypt work factor that will take around 1 second on this device.
///
/// Guaranteed to return a valid work factor (less than 64).
fn target_scrypt_work_factor() -> u8 {

😂 OK. That's the true reason.

it is expected that encryption and decryption takes at least a second,

I am new to cryptography. And I have no idea why it delay at least 1 second. I have test another crate aes-gcm, it seems this one has no obvious delay.

If you have time, do you mind make a clear and easy-to-understand instructions for the non-professional users? 🥺

str4d commented

I have test another crate aes-gcm, it seems this one has no obvious delay.

That is because it only implements the symmetric encryption part. This crate uses chacha20poly1305 for that purpose, which is similarly fast.

The reason for the 1 second delay when using a passphrase is because we can't know how secure the passphrase is on its own, and adversaries are very good at brute-force guessing passphrases (because humans are generally not great at picking passphrases). We follow best practices here by using a passphrase key derivation function (specifically scrypt) to derive the key used for the symmetric encryption; it's this step that takes the time. It's necessary to choose parameters that mean encryption and decryption takes a while (in this case, around a second), so that an adversary trying to brute-force guess the passphrase is also significantly slowed down. We target around a second as a decent trade-off between making users wait, and increasing the work adversaries need to do to brute-force the passphrase. This Stack Exchange answer has some more context you might find useful.

Excellent answer.