Suspect broken encryptions/decryptions under macOS Rosetta and virtualization

[enesusta]

Note

The original issue is answered in #633 (comment) and unrelated to the rest of the discussion starting with #633 (comment) and #633 (comment), which instead appear related as issues with running under macOS virtualization.

— @FiloSottile

Original issue

Environment

• OS: ubuntu 18.04 and macos 14.4
• age version: v1.2.1

What were you trying to do

I have a script that shows beloved, which backs my Sass database. How I'm using age while compress and encrypt the dump file.

this is happening on ubuntu

cat $CIHAN_FILE | xz | age -r [public-key] > $CIHAN_FILE.sql.xz.age

What happened

I still have the key.txt, but I can't decrypt the age files encrypted with the public key from key.txt using the same key.txt.

I'm trying to decrypt in macos

age -d -i key.txt cihan7-01_05_2025_18_00.sql.xz.age > cihan7-01_05_2025_18_00.sql.xz
age: error: failed to decrypt and authenticate payload chunk
age: report unexpected or unhelpful errors at https://filippo.io/age/report

[FiloSottile]

I'm afraid the file might be corrupted or truncated. age refuses to decrypt these files for security reasons.

I've been planning to add an age-recovery binary for insecurely decrypting damaged files.

[yboussard]

same issue for me (I don't understand):

machine 1:

$ md5sum docker/vault/.vault_pass.txt 
06241c204e3af468ae42635413a4045c  docker/vault/.vault_pass.txt
$ md5sum docker/vault/data/vault_backup_20251002_073505.json.enc 
d77b0176074eace68247d145a3806d35  docker/vault/data/vault_backup_20251002_073505.json.enc
$ uname -a
Linux  6.15.11-orbstack-00541-g75ba6c23ed9d #1 SMP PREEMPT Sat Sep 27 07:35:19 UTC 2025 x86_64 GNU/Linux
$ age --version
v1.2.1
$ age  --decrypt -i docker/vault/.vault_pass.txt -o /tmp/decrypt-2.json docker/vault/data/vault_backup_20251002_073505.json.enc
age: error: no identity matched any of the recipients
age: report unexpected or unhelpful errors at https://filippo.io/age/report

machine 2:

/ # md5sum /vault/.vault_pass.txt 
06241c204e3af468ae42635413a4045c  /vault/.vault_pass.txt
/ # md5sum /vault/backups/
Readme.md                                 vault_backup_20251002_073505.json.enc     vault_backup_20251002_073505.json.sha256
/ # md5sum /vault/backups/vault_backup_20251002_073505.json.enc 
d77b0176074eace68247d145a3806d35  /vault/backups/vault_backup_20251002_073505.json.enc
/ # age --version
1.2.1
/ # age --decrypt -o /tmp/vault_backup_20251002_073505.json -i /vault/.vault_pass.txt /vault/backups/vault_backup_20251002_073505.json.enc 
/ # uname -a
Linux 8d4cd67f356f 6.15.11-orbstack-00541-g75ba6c23ed9d #1 SMP PREEMPT Sat Sep 27 07:35:19 UTC 2025 aarch64 Linux

• If i encrypt a file on machine1 then machine2 can not decrypt this file
• If i encrypt a file on machine2 then machine1 can not decrypt this file

[ns-dfarino]

I am seeing a similar issue. I am on macOS Tahoe on a M1 mac, and am running age inside of a colima virtual machine.

For reference, this worked fine last week before I upgraded from Sonoma to Tahoe.

I'm suspecting this is a Rosetta issue because:

1. I can successfully decrypt in my macOS terminal outside of the colima VM.
2. I can successfully decrypt inside of the colima VM running the aarch64 version of the age executable.
3. It fails to decrypt when running the x86-64 executable inside of the colima VM:

root@colima:~# x86-64/age/age --decrypt -i key.txt /tmp/file.age 
age: error: no identity matched any of the recipients
age: report unexpected or unhelpful errors at https://filippo.io/age/report

The same x86-64 executable will successfully decrypt when run on a real amd64 machine (i.e. no Rosetta).

So, given all that, this feels like a Rosetta bug that was introduced between macOS Sonoma and Tahoe. I don't think this is your responsibility to fix, but I have no idea how to submit this to Apple. So I'm just posting it here for awareness.

Please let me know if I can provide any more information.

Thanks!

[FiloSottile]

@ns-dfarino that's worrying. I can escalate it to Apple, but I would like to isolate it a bit further first.

Could you run the age test suite in the x86_64 VM? It should be just a matter of running GOARCH=amd64 go test ./... (which passes on my macOS Sequoia).

Also, what happens if you use that binary directly on macOS, so with Rosetta but without virtualization?

[FiloSottile]

Oh, also, how did you build the binary? (What version of age, what version of Go, on what arch, etc.)

[ns-dfarino]

Hi @FiloSottile, thanks for taking a look. I'm using the executables downloaded from the GitHub releases section.

Here's a minimal test case:

$ system_profiler SPHardwareDataType SPSoftwareDataType
Hardware:

    Hardware Overview:

      Model Name: MacBook Pro
      Model Identifier: Mac15,7
      Model Number: Z1AJ0018XLL/A
      Chip: Apple M3 Pro
      Total Number of Cores: 12 (6 performance and 6 efficiency)
      Memory: 36 GB
      System Firmware Version: 13822.41.1
      OS Loader Version: 13822.41.1
      Activation Lock Status: Disabled

Software:

    System Software Overview:

      System Version: macOS 26.1 (25B78)
      Kernel Version: Darwin 25.1.0
      Boot Volume: Macintosh HD
      Boot Mode: Normal
      Secure Virtual Memory: Enabled
      System Integrity Protection: Enabled
      Time since boot: 4 days, 2 hours, 39 minutes
      
$ colima --version
colima version v0.8.1

$ limactl --version
limactl version 1.2.1

$ colima ssh

user@colima:~$ lscpu | grep Arch
Architecture:                         aarch64

user@colima:~$ mkdir arm64
user@colima:~$ curl -fsSL https://github.com/FiloSottile/age/releases/download/v1.2.1/age-v1.2.1-linux-arm64.tar.gz | tar -zx -C arm64

user@colima:~$ mkdir x86_64
user@colima:~$ curl -fsSL https://github.com/FiloSottile/age/releases/download/v1.2.1/age-v1.2.1-linux-amd64.tar.gz | tar -zx -C x86_64

user@colima:~$ arm64/age/age-keygen >identity
age-keygen: warning: writing secret key to a world-readable file
Public key: age1mmk0zgkpn90s5z8f99tuerckc7nhg6qagr9dy73wq4g8txcwsvss69akxw

user@colima:~$ echo testing >foo

user@colima:~$ arm64/age/age -i identity -o foo.encrypted -e foo

user@colima:~$ x86_64/age/age -i identity -d foo.encrypted
age: error: no identity matched any of the recipients
age: report unexpected or unhelpful errors at https://filippo.io/age/report

user@colima:~$ arm64/age/age -i identity -d foo.encrypted
testing

Interestingly, sometimes the x86_64 decryption succeeds. This is dependent on the specific foo.encrypted file. Meaning: for some outputs of the encryption command, the x86_64 decryption will succeed, and will always succeed on subsequent runs of the decryption command for that same encrypted file.

However, as shown above, sometimes I run the encryption command and its output causes the x86_64 decryption to fail. It will always fail on subsequent runs for that same encrypted file.

In either case, the arm64 decryption command always succeeds.

Swapping the executables for encryption and decryption behaves similarly (i.e. it will sometimes work and sometimes fail):

user@colima:~$ arm64/age/age -i identity -o foo.encrypted -e foo
user@colima:~$ x86_64/age/age -i identity -d foo.encrypted
testing
user@colima:~$ arm64/age/age -i identity -o foo.encrypted -e foo
user@colima:~$ x86_64/age/age -i identity -d foo.encrypted
age: error: no identity matched any of the recipients
age: report unexpected or unhelpful errors at https://filippo.io/age/report

Encrypting and decrypting with the x86_64 executable always seems to work:

user@colima:~$ x86_64/age/age -i identity -o foo.encrypted -e foo
user@colima:~$ x86_64/age/age -i identity -d foo.encrypted
testing

Likewise, using the arm64 executable always seems to work correctly:

user@colima:~$ arm64/age/age -i identity -o foo.encrypted -e foo
user@colima:~$ arm64/age/age -i identity -d foo.encrypted
testing

Note: when I say "always" in any of the above, I mean I tested approximately 10 times in a row. In cases where it fails, I was able to easily produce the failure case in about 50% of the attempts.

Please let me know if you'd like me to try any other scenarios.

Thanks!

[FiloSottile]

Thank you for all these details! Could you try the same thing but with the macOS amd64/arm64 binaries to figure out if the issue is Rosetta or Rosetta+Virtualization?

[FiloSottile]

Given x86_64 -> x86_64 always works, and arm64 -> arm64 always work, and when a specific x86_64 -> arm64 encryption works it keeps working, I think what we are observing is that some X25519(scalar, point) input pairs are deterministically mis-executed by the x86_64 program. That results in making a broken encrypted file (which arm64 can't decrypt) or in failing to decrypt an encrypted file. This is potentially a security issue.

I made a small test program that just does a few random X25519 operations, to check that this is indeed what is happening.

x25519debug.zip

Could you run the four binaries in that zip (the two Linux ones inside colima, the two Darwin ones on the macOS host) and report their output? If you'd like not to run a binary from a guy on the internet (very fair!) you can recompile them with:

GOOS=linux GOARCH=amd64 GOTOOLCHAIN=go1.23.4 go build -o x25519debug_linux_amd64 -trimpath x25519debug.go
GOOS=linux GOARCH=arm64 GOTOOLCHAIN=go1.23.4 go build -o x25519debug_linux_arm64 -trimpath x25519debug.go
GOOS=darwin GOARCH=amd64 GOTOOLCHAIN=go1.23.4 go build -o x25519debug_darwin_amd64 -trimpath x25519debug.go
GOOS=darwin GOARCH=arm64 GOTOOLCHAIN=go1.23.4 go build -o x25519debug_darwin_arm64 -trimpath x25519debug.go

[rsc]

Using an M4 MacBook Air just updated to macOS 26, I rebuilt the two darwin binaries using the commands above, and they print identical output:

d9877ece6d368aac1a6f419ec627c76b1bfb1fa37c41a11ea46add6a48d89474 7aed1486dbc47ffde80a1db27763daeb4dbb38d0fe6d40ded27d51366f20f767 3a9be75b79778087ad4c028de4214d1367bc91e693a59cf1bdd64433349d5109
4d2e566f8ddd78f34cf4929ef54f635daba384368d8c8542dcb8a99468ef7de3 db2abde1da43b41cc2c107ca7d098a9ae491d0ffd95fdb9c2e23da5247027d71 04fcc72ab458ad20255a3045bb32186d592412251eb92805d6e0126126f7a50e
2c840ec3c0fd581243cea3e828a15c70ce9a7f3b59f9a2aae3eb28cb670f0e97 ce5afd587e886192ca93ab5efea326eb26bdb1c77f81158606387693d0830245 0c860a7be804e1ce17a3046f5b249bb57db83e5e9703f5019171b141a73d9b45
181be188dcf20f8fd8d1001f787c1704ef711a1ed566a26b68b5c68785829264 a54de8761057cb0f26cf66480b228de594cdf550a12cab535e6b12160707d65d 3b40a282431604357764e691eb11f67896a9c48c3a0612a949b34a4892dada26
984ce1725032ec3855b970d3ecbf14bdb9216f41bbc5da98b7dafc64deb68410 f840492df9b86b41338bc75adeb58929600da617a40916473eb6b17cf073144d 631db4938f544a75b02d5170382b39dd95983b91e2a9e3f2fbd1d0a13a8a605e
9f445367ee0c6f56d3e59bdef423e884456d56198b872a65aadc8f829e0ce35c 80b9a553c896e267e698a8895f3eaf6c1f06e57e3bb0c8e397ecbc61d1eabf76 4741435df942a1f15ff91d244613e5f1d37dec9f9737ef6c1c405de2814c521e
314a42a39f8abf25a775a4810dd20a80da86b0011deb21bbdf31b5282bbc3d9a c575a945ba3530e7f551c9297621a9a4fe6ae0b9ad6374a56f7b7e640768b839 9707071671dede6a7c91cc9aeecab1e377edc150dd1b2de504970373e66d673f
387bfdb84b56e5d870aa5fa26ca01c380e0cfe42821e68aaba340af96279bf01 d492da0ce13c08e71070aecd1959ee3dcb37c6219d48ff8f0f5b3fb944f44758 a12013a25689cb2e0b3a832a0e59529ade8c6077db9f4ef7a5ac3e9076df2f7e
837fefe5279cfc9e0e427b01e9fa49a31e4cb12690cafb7aa0fe81b34c7f8050 26d3fad1ab494d19171def955d9db4ef4d911c06d3e589e1340362076a9d307e beff3c5fda5282ea65c775d246c491a3a556203882b26665922bd10ebe99062c
a94911c891eeb22514bdb20f9675ae25ecc97fc250c8ac1300d0e937a152a4fd a074ac3c74cb451e2b5ea1a26cacd9a7535cb57de4ef8ccb5b41437afce14b7c 7ff1f5bec1482c5eb1bdc8f571501e382748aba53939ce88397a059a3371bd4f
3e01c3d906865c6f37491e5f0ae4ba1caacf9b68a5267c6c5fc087cb70df5b51 6f5355c043d402dc0fd43a411260f49a0ad30630c86f795df626f4a98d36351e 0463d8a00178425c1ea8e58a729cfec97bba4098344290359b21646791197628
6eccf1bba9c5284e429173d13425349a5ff4c8fd651e175aeeb74f5a77e95d3b 4870ebd0bb96a91b7cb4c3b5e46b94e8e30198d942b805d2bfd8d240d2231a03 51c81719f65296518aabb4bdac4550034f18a08ec777c3a91d2939a9abeecd69
21473e89362f469b73acc6c3565825a0d50f51f96e722347d72b59b8227d4506 6ceb6c0279bf6874994cedce60eafb9c3299f4329018c2d249528ffc2d5e987e df13fa7e53364a3ff5f5ce8e2c3613e62af8f12ebf830966609d9a5acd5ba12b
a1ced239de959f76bf5ab58c8e61eb900c72ee7e53331554dcf76aa0aa1a4dc4 d9b4f09570e75bd74dc7fdb2c884837da93c7feb13da1614b3e6033c0aa1be43 09ae72de0ea3f94b60672d99af8659a8781999000686814e7cb0b43fc1642659
33f157282afa440dfb679aac0dc09769e61d1fb237cde886938a75b111a52d46 c6231ae6d5a103911fb83c422589f0583e512a315ef87a6a693cf11f4d98c43d 8ece1ebc266e822d0edd4e95b992dcabe23e3e5209736a29f9f94f3ce62c4019
c8c839492da3b333bb25d77bb39f40c55e4890521e53b60d5382898c849e5abe e378ab60a18499ec30c85d378fa6547df4569c3261b327c9d052c718b61ae47a 295b35e9d70bb0091b4eebb8bd666b0e1b3350fa0113b387913295fc1d0da34e
628d82cf7ecd46913e83149a5f2feb67e8b3595252b390386d06240c1e08b578 f3c6ccb872fcdf6d5fb62a1ed567ff47a9eedd39018664a08527606a6a95f12e 840387ef1309e6fd0fad615c7b5292ca4d077eecf0212ab73d685b26d1ba3873
177ed7038108641d499af66bed112e78e685815248a7a29709e2007b87270bb1 9429d48f285e486bcc1683779c61e090ad3a53be83c22fd83b94768e0d18cd4d ae4cd763cc1fdafcf9237f29f5ce7cbc869ccfdc63fc6d6b189ca123c2cf604c
59f50c2bf3db897f60eeddc708e2d75f8e6ace6ba25365a25332d537b95eef80 ff4745c26f2416a43265295e2990447b8d08b677ad3aa91bee062b17c5514f56 144bb778871bf3bf8cae51d4ca228fe04adb1384dc7d2b3c32a672cdf3bd173b
e29f79c7ead1f14912f238a56d59736908f3fe1ad87a97e8c2cd89d8a4799eef d2546777740520b92ef2ab3c3bfff1d9843d990ff9ffa0f588bd52813d7d6379 7970ba36a98d94cf271f11efe3dbae8e8bac63d84c395127444bd4002dba8347
fb144320b847203f0929d71336fdf5b0dd2ec5603046950c64ec0f9968bbaa21 5be1b1a28a543e6207aabcf5df1d90ce57261b942d6519d0c94843be431f9573 ee8d6ef7fd15f0d9f3c7683499e186ce3bad361ce2ebea75cafd759b1dba3314
2fa4883dfaeedceff70e90b8f300385778a7fccc2a97681fbdc400b69b983b9e 7bb05a00a9027df7810288b2d5dd55af4b2e3f74ded7ff31bef2b10c934dbd51 994e97de7f846e0280ee378b679bc847a4575093487b548ba07c1539e139562b
643cff2836d178e815f7619aaa157a1f2ac9312fdf8231819bc20ccbc82cea86 412510082542947fd6c3c75d74f6fa0223eb62b2016978bb481d40ec45d6da4a a84af2cf6befb3f252d4ebf0a1fd0b75deeb871ba2ec49dafeeb3dec2894cf2c
44374e8b34b4eb1b5c17c3998763199d7d294126d3a9fcccfe568512a242b356 5bea84ab36aa5138cac38da8be0c3bfb141990f5060ab2aab6a1c451464f9f61 e57c1af3b0f69529ce6cf963423d74da042fae4155e9aca69494987dbb012c08
187cf76e34c02e333976e4ef048cbe3de5e6e6d31eb1cfb64bf44cc939358b5e 2573bcc76f14d2d31ae5bf67882e63fee3cf5dcb3134dda62dd2e6bb67756c49 698224dc161c71aa528d8dadb7d2949e14f1e8571fcf1fd302bc573a2cc78e4a
f3f858b87ceb2581fe4448981a23163565c67f4726b3a0ed6f24aa5c01fa44c3 100a78d6969c464a7e9261471e03e100324b276c3e590309a68369edb1fd437b ef4f8fe7f9c68c4039b99012d358306f95690623961933e51fb4590dd4f62900
e18f5366760583a4b9f383dc323d0935c3267e2ba58ffb4bc7cef9abe2b5c223 1db90ddacf28080c5b34286bdf6f6c8d830ea9d21bab349771ef4357337b250c 4830ae8f2d72c1643117ca3ba470c4ef4debd3d9239d515e7aa5e1b99845c92f
bd7d25b0535d7c7d81edd9afecec5cbd0d4c25069aa7c5aa7c15b8eaa95d19f8 1bd3b25f6873aec3c98e0b5e5c7fcfd559e1b2be353228ae8eed74a10b050018 9fd477c8976e94dae700764837a06dcc171b70fb75d9401957e12c08d0bfe053
f6c3ffed113df765e6283dfd9872c33e79f58ece16a008a92b72c68e29a4dbb2 569b1c70232dfa6a97d222d92ec4df024826ec30f10897883a76808161315246 dcdcebdb522dda1827ee4673439c6e66267d17c899850ef5673cad6e3469e975
a88080c57140027616d9a6693501638d6070be4aa8cb06d47e54d6b557c009e9 cd5ef3d9045520f9ec82f9f3c442defd23624fb738d7f5360f4513549fc8034e b17c92a8bf32f427470b65cde4a8dfe5ff57cd9a684a064ed86e165c6d41ce0a
325bafddff20cf4c57d5b1a837ba779e94f2e39e8f91260ca05c2a0b311d9471 39b2c1b3dce8ff83f4d3eedbb0310257afc0814cd14400fe5b9a3890df69b028 df3964114914fcb024334a6df993bf74c581d90556a42f03d6dadaf82fb61c3e
f9ac6f31d472458d0b18e51db4d7f948465f83c35bc359ac503c7e2f73aa1450 d7ddc46a84baf3125652a5b21d90e850c047a8d9172763d454e1b4dcf99dea6a e57a0e0a9bff170af8ed98a0baf580343a5d55b888f4ca781b332821efc90436
8d5f6f7dd10430d136511c4fed66147b08f53404ecf22d740190ad45ebfc17eb

[rsc]

I tried in colima and still get the same outputs. I also tried the script from the original poster, encrypting a 'testing' file using arm64 and decrypting it again using x86_64 (both under colima), and I have run thousands of round trips without any failures.

I saw a segmentation fault twice out of more than 2000 runs. I tried running the age tests using an amd64 Go in colima and saw cmd/compile and cmd/vet segmentation fault once as well. Rosetta seems not well.

I am using an M4 MacBook Air, not the M3 MacBook Pro in the original report. I believe I am using the same software.

[ns-dfarino]

@FiloSottile here are the results from using the darwin executables on macOS (no colima):

$ mkdir arm64
$ curl -fsSL https://github.com/FiloSottile/age/releases/download/v1.2.1/age-v1.2.1-darwin-arm64.tar.gz | tar -zx -C arm64
$ file arm64/age/age
arm64/age/age: Mach-O 64-bit executable arm64

$ mkdir x86_64
$ curl -fsSL https://github.com/FiloSottile/age/releases/download/v1.2.1/age-v1.2.1-darwin-amd64.tar.gz | tar -zx -C x86_64
$ file x86_64/age/age
x86_64/age/age: Mach-O 64-bit executable x86_64

$ arm64/age/age-keygen >identity
age-keygen: warning: writing secret key to a world-readable file
Public key: age1gu9lmkyagx7wzt7ke386gf6as4cqpru5fs69eykdge46kvj84f8sm30r7k

$ echo testing >foo

$ for i in {0..5}; do x86_64/age/age -i identity -o foo.encrypted -e foo; arm64/age/age -i identity -d foo.encrypted; done
testing
testing
testing
testing
testing
testing

$ for i in {0..5}; do arm64/age/age -i identity -o foo.encrypted -e foo; x86_64/age/age -i identity -d foo.encrypted; done
testing
testing
testing
testing
testing
testing

Both variations work 100% of the time up to 2000 iterations.

For the x25519debug experiment, I ran your binaries from the zip file. All four runs produced identical output:

d9877ece6d368aac1a6f419ec627c76b1bfb1fa37c41a11ea46add6a48d89474 7aed1486dbc47ffde80a1db27763daeb4dbb38d0fe6d40ded27d51366f20f767 3a9be75b79778087ad4c028de4214d1367bc91e693a59cf1bdd64433349d5109
4d2e566f8ddd78f34cf4929ef54f635daba384368d8c8542dcb8a99468ef7de3 db2abde1da43b41cc2c107ca7d098a9ae491d0ffd95fdb9c2e23da5247027d71 04fcc72ab458ad20255a3045bb32186d592412251eb92805d6e0126126f7a50e
2c840ec3c0fd581243cea3e828a15c70ce9a7f3b59f9a2aae3eb28cb670f0e97 ce5afd587e886192ca93ab5efea326eb26bdb1c77f81158606387693d0830245 0c860a7be804e1ce17a3046f5b249bb57db83e5e9703f5019171b141a73d9b45
181be188dcf20f8fd8d1001f787c1704ef711a1ed566a26b68b5c68785829264 a54de8761057cb0f26cf66480b228de594cdf550a12cab535e6b12160707d65d 3b40a282431604357764e691eb11f67896a9c48c3a0612a949b34a4892dada26
984ce1725032ec3855b970d3ecbf14bdb9216f41bbc5da98b7dafc64deb68410 f840492df9b86b41338bc75adeb58929600da617a40916473eb6b17cf073144d 631db4938f544a75b02d5170382b39dd95983b91e2a9e3f2fbd1d0a13a8a605e
9f445367ee0c6f56d3e59bdef423e884456d56198b872a65aadc8f829e0ce35c 80b9a553c896e267e698a8895f3eaf6c1f06e57e3bb0c8e397ecbc61d1eabf76 4741435df942a1f15ff91d244613e5f1d37dec9f9737ef6c1c405de2814c521e
314a42a39f8abf25a775a4810dd20a80da86b0011deb21bbdf31b5282bbc3d9a c575a945ba3530e7f551c9297621a9a4fe6ae0b9ad6374a56f7b7e640768b839 9707071671dede6a7c91cc9aeecab1e377edc150dd1b2de504970373e66d673f
387bfdb84b56e5d870aa5fa26ca01c380e0cfe42821e68aaba340af96279bf01 d492da0ce13c08e71070aecd1959ee3dcb37c6219d48ff8f0f5b3fb944f44758 a12013a25689cb2e0b3a832a0e59529ade8c6077db9f4ef7a5ac3e9076df2f7e
837fefe5279cfc9e0e427b01e9fa49a31e4cb12690cafb7aa0fe81b34c7f8050 26d3fad1ab494d19171def955d9db4ef4d911c06d3e589e1340362076a9d307e beff3c5fda5282ea65c775d246c491a3a556203882b26665922bd10ebe99062c
a94911c891eeb22514bdb20f9675ae25ecc97fc250c8ac1300d0e937a152a4fd a074ac3c74cb451e2b5ea1a26cacd9a7535cb57de4ef8ccb5b41437afce14b7c 7ff1f5bec1482c5eb1bdc8f571501e382748aba53939ce88397a059a3371bd4f
3e01c3d906865c6f37491e5f0ae4ba1caacf9b68a5267c6c5fc087cb70df5b51 6f5355c043d402dc0fd43a411260f49a0ad30630c86f795df626f4a98d36351e 0463d8a00178425c1ea8e58a729cfec97bba4098344290359b21646791197628
6eccf1bba9c5284e429173d13425349a5ff4c8fd651e175aeeb74f5a77e95d3b 4870ebd0bb96a91b7cb4c3b5e46b94e8e30198d942b805d2bfd8d240d2231a03 51c81719f65296518aabb4bdac4550034f18a08ec777c3a91d2939a9abeecd69
21473e89362f469b73acc6c3565825a0d50f51f96e722347d72b59b8227d4506 6ceb6c0279bf6874994cedce60eafb9c3299f4329018c2d249528ffc2d5e987e df13fa7e53364a3ff5f5ce8e2c3613e62af8f12ebf830966609d9a5acd5ba12b
a1ced239de959f76bf5ab58c8e61eb900c72ee7e53331554dcf76aa0aa1a4dc4 d9b4f09570e75bd74dc7fdb2c884837da93c7feb13da1614b3e6033c0aa1be43 09ae72de0ea3f94b60672d99af8659a8781999000686814e7cb0b43fc1642659
33f157282afa440dfb679aac0dc09769e61d1fb237cde886938a75b111a52d46 c6231ae6d5a103911fb83c422589f0583e512a315ef87a6a693cf11f4d98c43d 8ece1ebc266e822d0edd4e95b992dcabe23e3e5209736a29f9f94f3ce62c4019
c8c839492da3b333bb25d77bb39f40c55e4890521e53b60d5382898c849e5abe e378ab60a18499ec30c85d378fa6547df4569c3261b327c9d052c718b61ae47a 295b35e9d70bb0091b4eebb8bd666b0e1b3350fa0113b387913295fc1d0da34e
628d82cf7ecd46913e83149a5f2feb67e8b3595252b390386d06240c1e08b578 f3c6ccb872fcdf6d5fb62a1ed567ff47a9eedd39018664a08527606a6a95f12e 840387ef1309e6fd0fad615c7b5292ca4d077eecf0212ab73d685b26d1ba3873
177ed7038108641d499af66bed112e78e685815248a7a29709e2007b87270bb1 9429d48f285e486bcc1683779c61e090ad3a53be83c22fd83b94768e0d18cd4d ae4cd763cc1fdafcf9237f29f5ce7cbc869ccfdc63fc6d6b189ca123c2cf604c
59f50c2bf3db897f60eeddc708e2d75f8e6ace6ba25365a25332d537b95eef80 ff4745c26f2416a43265295e2990447b8d08b677ad3aa91bee062b17c5514f56 144bb778871bf3bf8cae51d4ca228fe04adb1384dc7d2b3c32a672cdf3bd173b
e29f79c7ead1f14912f238a56d59736908f3fe1ad87a97e8c2cd89d8a4799eef d2546777740520b92ef2ab3c3bfff1d9843d990ff9ffa0f588bd52813d7d6379 7970ba36a98d94cf271f11efe3dbae8e8bac63d84c395127444bd4002dba8347
fb144320b847203f0929d71336fdf5b0dd2ec5603046950c64ec0f9968bbaa21 5be1b1a28a543e6207aabcf5df1d90ce57261b942d6519d0c94843be431f9573 ee8d6ef7fd15f0d9f3c7683499e186ce3bad361ce2ebea75cafd759b1dba3314
2fa4883dfaeedceff70e90b8f300385778a7fccc2a97681fbdc400b69b983b9e 7bb05a00a9027df7810288b2d5dd55af4b2e3f74ded7ff31bef2b10c934dbd51 994e97de7f846e0280ee378b679bc847a4575093487b548ba07c1539e139562b
643cff2836d178e815f7619aaa157a1f2ac9312fdf8231819bc20ccbc82cea86 412510082542947fd6c3c75d74f6fa0223eb62b2016978bb481d40ec45d6da4a a84af2cf6befb3f252d4ebf0a1fd0b75deeb871ba2ec49dafeeb3dec2894cf2c
44374e8b34b4eb1b5c17c3998763199d7d294126d3a9fcccfe568512a242b356 5bea84ab36aa5138cac38da8be0c3bfb141990f5060ab2aab6a1c451464f9f61 e57c1af3b0f69529ce6cf963423d74da042fae4155e9aca69494987dbb012c08
187cf76e34c02e333976e4ef048cbe3de5e6e6d31eb1cfb64bf44cc939358b5e 2573bcc76f14d2d31ae5bf67882e63fee3cf5dcb3134dda62dd2e6bb67756c49 698224dc161c71aa528d8dadb7d2949e14f1e8571fcf1fd302bc573a2cc78e4a
f3f858b87ceb2581fe4448981a23163565c67f4726b3a0ed6f24aa5c01fa44c3 100a78d6969c464a7e9261471e03e100324b276c3e590309a68369edb1fd437b ef4f8fe7f9c68c4039b99012d358306f95690623961933e51fb4590dd4f62900
e18f5366760583a4b9f383dc323d0935c3267e2ba58ffb4bc7cef9abe2b5c223 1db90ddacf28080c5b34286bdf6f6c8d830ea9d21bab349771ef4357337b250c 4830ae8f2d72c1643117ca3ba470c4ef4debd3d9239d515e7aa5e1b99845c92f
bd7d25b0535d7c7d81edd9afecec5cbd0d4c25069aa7c5aa7c15b8eaa95d19f8 1bd3b25f6873aec3c98e0b5e5c7fcfd559e1b2be353228ae8eed74a10b050018 9fd477c8976e94dae700764837a06dcc171b70fb75d9401957e12c08d0bfe053
f6c3ffed113df765e6283dfd9872c33e79f58ece16a008a92b72c68e29a4dbb2 569b1c70232dfa6a97d222d92ec4df024826ec30f10897883a76808161315246 dcdcebdb522dda1827ee4673439c6e66267d17c899850ef5673cad6e3469e975
a88080c57140027616d9a6693501638d6070be4aa8cb06d47e54d6b557c009e9 cd5ef3d9045520f9ec82f9f3c442defd23624fb738d7f5360f4513549fc8034e b17c92a8bf32f427470b65cde4a8dfe5ff57cd9a684a064ed86e165c6d41ce0a
325bafddff20cf4c57d5b1a837ba779e94f2e39e8f91260ca05c2a0b311d9471 39b2c1b3dce8ff83f4d3eedbb0310257afc0814cd14400fe5b9a3890df69b028 df3964114914fcb024334a6df993bf74c581d90556a42f03d6dadaf82fb61c3e
f9ac6f31d472458d0b18e51db4d7f948465f83c35bc359ac503c7e2f73aa1450 d7ddc46a84baf3125652a5b21d90e850c047a8d9172763d454e1b4dcf99dea6a e57a0e0a9bff170af8ed98a0baf580343a5d55b888f4ca781b332821efc90436
8d5f6f7dd10430d136511c4fed66147b08f53404ecf22d740190ad45ebfc17eb

[rsc]

If Rosetta is causing random corruption (as evidenced by the seg faults of compile and vet) then certainly that would explain occasional crypto hash verification failures as well.

[FiloSottile]

Random corruption would not explain how some encrypted files always decrypt successfully. Decryption is deterministic, while encryption picks a random ephemeral X25519 share every time. Also, all the reported errors are no identity matched any of the recipients which suggests the X25519 computation failed and not anything related e.g. to the AEAD.

[ns-dfarino]

Here are a couple more interesting test cases, operating on the same identity and encrypted files inside and outside of colima.

1. When encrypting inside of colima using the x86_64 executable, the arm64 executable fails to decrypt, as do both the darwin arm64 and x86_64 executables outside of colima:

$ colima ssh

user@colima:~/work/age$ mkdir -p linux/arm64
user@colima:~/work/age$ curl -fsSL https://github.com/FiloSottile/age/releases/download/v1.2.1/age-v1.2.1-linux-arm64.tar.gz | tar -zx -C linux/arm64

user@colima:~/work/age$ mkdir -p linux/x86_64
user@colima:~/work/age$ curl -fsSL https://github.com/FiloSottile/age/releases/download/v1.2.1/age-v1.2.1-linux-amd64.tar.gz | tar -zx -C linux/x86_64

user@colima:~/work/age$ linux/arm64/age/age-keygen >identity
age-keygen: warning: writing secret key to a world-readable file
Public key: age1d896prp7m55kk7238d2ephvgmclzl262qkruhe4xzr7nah8el47qgcgmzn

user@colima:~/work/age$ echo testing >foo

user@colima:~/work/age$ linux/x86_64/age/age -i identity -o foo.encrypted -e foo

user@colima:~/work/age$ linux/arm64/age/age -i identity -d foo.encrypted
age: error: no identity matched any of the recipients
age: report unexpected or unhelpful errors at https://filippo.io/age/report

user@colima:~/work/age$ linux/x86_64/age/age -i identity -d foo.encrypted
testing

user@colima:~/work/age$ ^D
logout

$ mkdir -p darwin/arm64
$ curl -fsSL https://github.com/FiloSottile/age/releases/download/v1.2.1/age-v1.2.1-darwin-arm64.tar.gz | tar -zx -C darwin/arm64

$ mkdir -p darwin/x86_64
$ curl -fsSL https://github.com/FiloSottile/age/releases/download/v1.2.1/age-v1.2.1-darwin-amd64.tar.gz | tar -zx -C darwin/x86_64

$ darwin/arm64/age/age -i identity -d foo.encrypted
age: error: no identity matched any of the recipients
age: report unexpected or unhelpful errors at https://filippo.io/age/report

$ darwin/x86_64/age/age -i identity -d foo.encrypted
age: error: no identity matched any of the recipients
age: report unexpected or unhelpful errors at https://filippo.io/age/report

2. However, when encrypting inside of colima using the arm64 executable, the only failure is the x86_64 executable inside of colima. The darwin executables outside of colima decrypt correctly:

$ colima ssh

user@colima:~/work/age$ mkdir -p linux/arm64
user@colima:~/work/age$ curl -fsSL https://github.com/FiloSottile/age/releases/download/v1.2.1/age-v1.2.1-linux-arm64.tar.gz | tar -zx -C linux/arm64

user@colima:~/work/age$ mkdir -p linux/x86_64
user@colima:~/work/age$ curl -fsSL https://github.com/FiloSottile/age/releases/download/v1.2.1/age-v1.2.1-linux-amd64.tar.gz | tar -zx -C linux/x86_64

user@colima:~/work/age$ linux/arm64/age/age-keygen >identity
age-keygen: warning: writing secret key to a world-readable file
Public key: age18jm8wa8vjrkvf0t8unmtfgulzhze6hc6r2cls8a9lfhlqqxhnvrq3rd24a

user@colima:~/work/age$ echo testing >foo

user@colima:~/work/age$ linux/arm64/age/age -i identity -o foo.encrypted -e foo

user@colima:~/work/age$ linux/x86_64/age/age -i identity -d foo.encrypted
age: error: no identity matched any of the recipients
age: report unexpected or unhelpful errors at https://filippo.io/age/report

user@colima:~/work/age$ linux/arm64/age/age -i identity -d foo.encrypted
testing

user@colima:~/work/age$ ^D
logout

$ mkdir -p darwin/arm64
$ curl -fsSL https://github.com/FiloSottile/age/releases/download/v1.2.1/age-v1.2.1-darwin-arm64.tar.gz | tar -zx -C darwin/arm64

$ mkdir -p darwin/x86_64
$ curl -fsSL https://github.com/FiloSottile/age/releases/download/v1.2.1/age-v1.2.1-darwin-amd64.tar.gz | tar -zx -C darwin/x86_64

$ darwin/arm64/age/age -i identity -d foo.encrypted
testing

$ darwin/x86_64/age/age -i identity -d foo.encrypted
testing

[FiloSottile]

I can't get it to reproduce on Sequoia. The error looks precisely like X25519 is mis-executed for certain inputs, but x25519debug being unaffected is hard to explain. It would be great to hear if anyone else can reproduce it.