data_read() can encrypt/decrypt R data files

[strengejacke]

No description provided.

[strengejacke]

@gemini-code-assist review

[Copilot]

Pull request overview

This PR introduces optional password-based encryption/decryption support to the data_write() / data_read() I/O wrappers, primarily targeting native R file formats.

Changes:

• Add a password argument to data_write() and data_read() and implement encrypt/decrypt helpers.
• Add tests for encrypted .rds / .rdata round-trips and ensure unsupported formats error when password is provided.
• Update documentation, NEWS, and package metadata to reflect the new feature and dependency.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
R/data_write.R	Adds password plumbing plus encryption helpers and format-specific guards.
R/data_read.R	Adds password plumbing plus decryption helpers for base R readers.
tests/testthat/test-data_write.R	Adds test coverage for encrypted R formats and unsupported encryption paths.
man/data_read.Rd	Documents the new password parameter for both read/write.
NEWS.md	Announces the new encryption/decryption capability and supported formats.
DESCRIPTION	Adds openssl to Suggests and bumps version.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[etiennebacher]

I don't feel knowledgeable enough to review this PR. I've never had to interact with password-protected datafiles and I don't know the best practices in encryption/decryption.

Also, I don't see any feature request to handle encrypted files in haven or readr, so I think this is rare enough to let users explicitly handle it rather than doing some internal magic for them. I don't think the potential usability gain is worth the extra maintenance effort and risk.

[strengejacke]

I used this script to encrypt/decrypt data for a longer time now, and it's quite simple. I don't think the maintenance effort is very high. It's quite convenient, because data encryption is increasingly important (and awareness is raising). My colleagues use a password-protected zip-folder, which is of course annoying to handle. Same for loading and running the R script. I think a direct implementation is very practical.

[etiennebacher]

My concern is that this becomes the top result when people search for "R write password protected rda" while I'm not confident this follows best practices in security. For example, the current implementation uses:

• openssl::sha256() but why not md5(), or sha512(), or ...
• openssl::aes_cbc_decrypt(), but why not aes_ctr_decrypt(), or aes_gcm_decrypt(), or ...

My point is that there are various key components that we're just hiding from the user here and where we assume we make the right choice for them, but I'd rather have them being explicit about the functions they're using to secure data. The implementation is 4-5 lines for each so I don't think it's too hard for users (we could also add a line in docs to redirect them to openssl to encrypt/decrypt data).

Curious about @easystats/core-team opinions here

[strengejacke]

Ok, I see the point. So the minimum, if we decide on integrating such a feature, would be to use more up-to-date encryption standards?

[etiennebacher]

Yes but also give the user more choice to use the method they want. But my point was also that since the implementation is very simple, I think we'd just be better off documenting how to do this and redirect to openssl or other encryption/decryption-focused packages without having to maintain something to do that ourselves.

[strengejacke]

After a little chat with Gemini, I learned that sha512 is the most secure hash key generation, and gcm-encryption is the most secure encryption method, so I updated the code here. I think this is in line with the help file from openssl.

I think we'd just better off documenting how to do this and redirect to openssl or other encryption/decryption-focused packages

But part of the easystats philosophy is to keep these confusing stuff away from users. Most of the people around me who work with R can use basics, maybe a bit of programming, but would not know how to encrypt/decrypt data (or other stuff). That's why I think it's convenient to have it here, and I don't think it will lead to "bad practices" in terms of "bad encryption" or security. Rather, if there's no easy-to-understand way how to encrypt files, it's often not done at all. So we would definitely have an improvement here for casual users, that's my impression.

[etiennebacher]

Ok, that sounds reasonable to me. I suggested several changes to docs and tests below.

[etiennebacher]

sha512 instead of sha256?

Also, this should mention that the decryption method only works when the file was encrypted with data_write() or in another function but still using openssl::sha512

[strengejacke]

I first switched to sha512, but that doesn't seem to be supported by the openssl-functions. That's why I switched back to sha256:

passphrase <- charToRaw("This is super secret")
x <- serialize(iris, NULL)

key <- openssl::sha256(passphrase)
y <- openssl::aes_cbc_encrypt(x, key = key)

key <- openssl::sha512(passphrase)
y <- openssl::aes_cbc_encrypt(x, key = key)
#> Error in `aes_any()`:
#> ! key must be of length 16 (aes-128), 24 (aes-192) or 32 (aes-256)
y <- openssl::aes_ctr_encrypt(x, key = key)
#> Error in `aes_any()`:
#> ! key must be of length 16 (aes-128), 24 (aes-192) or 32 (aes-256)
y <- openssl::aes_gcm_encrypt(x, key = key)
#> Error in `aes_any()`:
#> ! key must be of length 16 (aes-128), 24 (aes-192) or 32 (aes-256)

^{Created on 2026-04-16 with reprex v2.1.1}

[strengejacke]

Will continue working on docs/tests later

[strengejacke]

Ok, I think all comments are addressed now.

[etiennebacher]

Thanks! Just waiting for CI to be green