Differences

This shows you the differences between two versions of the page.

--- pgpfan:agevspgp [2021/12/30 23:01] – [File Substitution] Typo. b.walzer
+++ pgpfan:agevspgp [2024/08/06 20:53] (current) – [File Substitution] From a HN comment. b.walzer
@@ Line 83: / Line 83: @@
 At this point you might want to consider how often longer term backups end up with bad sections. Then consider how many attackers exist with sufficient skill, combined with sufficient knowledge of the organization and content of your backups to do reliable changes. Attackers that are willing to have their efforts revealed after the first attempt. This would seem to be where OpenPGP is superior to age.
-The ultimate point here is that "blowing up with an error" might not be the best way to handle this sort of situation in a command line utility. A lesson from application programming is that it is often better to complete the operation and return the error at the end.
+Another more specific example could be the storage of passwords as is done with [[https://www.passwordstore.org/|passwordstore]]. If an encrypted password was corrupted in some way, the user would very much want access to the results of attempting to decrypt the password. Anything would be better than nothing in that case. Age would deliberately refuse to return anything.
+I admit that the previous two examples are contrived. But they are much less contrived than the example of the encrypted tar file. A lesson from application programming is that it is often better to complete the operation and return the error at the end. That seems to be the case for a command line utility that does encryption.
 ====File Substitution====
-Public key encryption has a generic consideration that is quite relevant here. Anyone with access to the public key can easily create a file that will pass any file modification tests ... because after all //that// file has not been modified after creation. You can try to keep the public key secret but a public key design does not guarantee that the public key can not be derived from the encrypted material. That guarantee only applies to the secret key. So an attacker can skip the bother of attempting to overcome the authentication and just replace the file with whatever they want.
+Public key encryption has a generic consideration that is quite relevant here. Anyone with access to the public key can easily create a file that will pass any file modification tests ... because after all //that// file has not been modified after creation. So an attacker can skip the bother of attempting to overcome the authentication and just replace the file with whatever they want.
 The traditional fix for this weakness is to cryptographically sign the file ... and, once again, age does not do signatures. An age user would need to go through the process of finding a separate signing utility and would have to apply it correctly while using a separate signature file. A GnuPG user would only have to add a ''%%-s%%'' option while encrypting and would have an integrated signature protected by the encryption. No further effort would be required on the part of the GnuPG user. A good signature message would appear automatically after decryption.
+The creator of age has suggested that you can just keep the recipient identity (public key) away from the attacker and prevent them from creating a valid ciphertext to produce a sort of authentication for age(([[https://words.filippo.io/dispatches/age-authentication/|age and Authenticated Encryption]])). The fundamental issue with that idea is that it depends on a poorly specified property of the cryptography. Any protection against an attacker being able to derive the public key is merely accidental. The creator of age said in an article:
+>I am confident the property holds for the X25519 recipients, and that it would hold for a hypothetical Kyber768+X25519 one,...
+... but provided no explicit argument to that effect. ... and then continued:
+>...but it's important not to advertise it as an age-wide property.
+In practice the recipient identity key will show up on the command line and/or will be kept in an unencrypted file. So age itself treats it as a potentially public value.
+If you and the recipient have the ability to share and keep a secret value secret, why use asymmetrical encryption in the first place? Symmetrical encryption is specifically intended to authenticate in that case. Or why not put that secret value in the plaintext as discussed in an article by the creator of age? The reason that there is not more research into the security of secret recipient identities is because there is no practical value in such use.
 =====Conclusion=====