The Call of the Open Sidewalk

From a place slightly to the side of the more popular path

User Tools

Site Tools

pgpfan:agevspgp

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
pgpfan:agevspgp [2021/01/02 20:52] – [Signed Backups] added point b.walzerpgpfan:agevspgp [2024/08/06 20:53] (current) – [File Substitution] From a HN comment. b.walzer
Line 34: Line 34:
 The issue here is that tar might of had to deal with garbage for input. A potentially more serious issue would be if a malicious entity had enough knowledge of the unencrypted backup to allow them to modify files and/or file locations in a purposeful way. This might be a concern if you store your backups on a server that is not under your control. The issue here is that tar might of had to deal with garbage for input. A potentially more serious issue would be if a malicious entity had enough knowledge of the unencrypted backup to allow them to modify files and/or file locations in a purposeful way. This might be a concern if you store your backups on a server that is not under your control.
  
-Age does an integrity check every 64KB along the encrypted stream. If the integrity check fails then it does not release the bad 64KB chunk and errors out thus truncating the output. This truncation might cause a problem in some cases, but the assumption is that no data is better than bad data.+Age does an integrity check every 64KB along the encrypted stream. If the integrity check fails then it does not release the bad 64KB chunk and errors out thus truncating the output. This allows an attacker to terminate your process at any point they choose. The assumption here is that no data or partial data is better than bad data.
  
 The solution to the GnuPG bad data and the age truncated data is the same. Check the integrity of the input file before attempting to do anything with it. I would think this step would be mandatory in a case where there is a possibility that someone might attempt to modify your encrypted file(s). A manual integrity check could be as simple as running GnuPG and dumping the output to see if an error message shows up: The solution to the GnuPG bad data and the age truncated data is the same. Check the integrity of the input file before attempting to do anything with it. I would think this step would be mandatory in a case where there is a possibility that someone might attempt to modify your encrypted file(s). A manual integrity check could be as simple as running GnuPG and dumping the output to see if an error message shows up:
Line 42: Line 42:
 ====Data Recovery==== ====Data Recovery====
  
-Here is what this would look like in practice using the example of a single flipped bit near the start of the encrypted file. First age:+To be clear, "recovery" here is the sifting of good data from bad. Neither age or GnuPG can regenerate good data from redundant bad data. 
 + 
 +Here is what this would look like in practice using the example of a single flipped bit((Please note that the single flipped bit here is not a realistic example and that in practice damage tends to encompass one or more media blocks. Such blocks tend to be multiples of 512 bytes. Often the blocks are entirely missing.)) near the start of the encrypted file. First age:
  
   $ age -d -i key.txt -o totc_out.txt totc.txt.age   $ age -d -i key.txt -o totc_out.txt totc.txt.age
Line 51: Line 53:
   -rw-r--r--  1 operator  operator  0 Dec 25 12:53 totc_out.txt   -rw-r--r--  1 operator  operator  0 Dec 25 12:53 totc_out.txt
  
-Age has returned a zero length file. Those that have spent time maintaining backups for others might be suffering some vicarious anxiety at this point. A single bit error has nerfed the entire backup. The knowledge that there is no recovery mode or utility available for age will probably not help with that anxiety. I was not able to determine if such a recovery utility was possible as there does not seem to be enough of a description available to determine how the 64KB chunks relate to one another. +Age has returned a zero length file. Those that have spent time maintaining backups for others might be suffering some vicarious anxiety at this point. A single bit error has nerfed the entire backup. There is no recovery mode or utility available for age which makes the recovery capability provided by your compression utility((The commonly used bzip2 compression utility for example is specifically designed to be recoverable and comes with the ''%%bzip2recover%%'' command.)) worthless. 
 + 
 +The published standard for age (([[https://docs.google.com/document/d/11yHom20CrsuX8KQJXBBw04s80Unjv8zCg_A7sPAX_9Y/preview|A simple file encryption tool & format]])) is incomplete. I was not able to determine if a recovery utility was even possible as the standard does not provide a description of how the 64KB chunks relate to one another. Creating a recovery utility would be harder due to this lack of documentation. 
 + 
 +It is quite common for media problems to result in the loss of one or more media blocks. Since the 64k chunk used by age is likely going to be larger, an age recovery process would require a search for the start of the next chunk.
  
 Now GnuPG: Now GnuPG:
Line 73: Line 79:
   ...   ...
      
-So we have lost 5 words out of 800KB of text((GnuPG noticed that I was encrypting text and helpfully compressed it thus eliminating my example. The addition of a "--compress-algo none" option at encrypt time was required. Almost all backups are separately compressed. GnuPG will not recompress input. So GnuPG still gets credit for good recoverablity for the backup case using default options.)). This is an example of a somewhat unknown and under appreciated feature of the type of encryption used in OpenPGP. It is self-synchronizing in the face of corruption.+So we have lost 5 words out of 800KB of text((GnuPG noticed that I was encrypting text and helpfully compressed it thus eliminating my example. The addition of a ''%%--compress-algo none%%'' option at encrypt time was required. Almost all backups are separately compressed. GnuPG will not recompress input. So GnuPG still gets credit for good recoverablity for the backup case using default options.)). This is an example of a somewhat unknown and under appreciated feature of the type of encryption used in OpenPGP. It is self-synchronizing in the face of corruption. The "chunk" in this case is only going to be something like 16 bytes which is going to be shorter than the media block so there is no search required to find the next good "chunk". As a result, no recovery mode or utility is required for GnuPG in almost all cases. Recovery is automatic with a provided warning and returned error.
  
 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. 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.
  
-====Signed Backups====+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.
  
-Doing backups in this way means that you have to keep the public key secret. Otherwise an attacker could replace something like a backup with a completely new file that would pass the integrity check(s). If the public key can not be kept secret then the backup would have to be signed. That would be as simple as adding a "-s" option when encrypting using GnuPG. Since age does not do signatures you would have to use a separate utility and would end up with a separate signature file to deal with. I find it slightly ironic that in most situations GnuPG would be the most available and easiest choice for that added signature. This could be another place where OpenPGP is superior to age.+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. 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===== =====Conclusion=====
  
 Age should be considered where a simple encryption utility is needed that will not under any circumstances release unauthenticated data. Where that behaviour is undesirable, such as for encrypted backups, something based on OpenPGP would be preferred. Age should be considered where a simple encryption utility is needed that will not under any circumstances release unauthenticated data. Where that behaviour is undesirable, such as for encrypted backups, something based on OpenPGP would be preferred.
 +
 +[[pgpfan:index|PGP FAN index]]
  
pgpfan/agevspgp.1609620761.txt.gz · Last modified: 2021/01/02 20:52 by b.walzer