The hardware and bandwidth for this mirror is donated by METANET, the Webhosting and Full Service-Cloud Provider.
If you wish to report a bug, or if you are interested in having us mirror your free-software or open-source project, please feel free to contact us at mirror[@]metanet.ch.
This package tries to smooth over some of the differences in encryption approaches (symmetric vs. asymmetric, sodium vs. openssl) to provide a simple interface for users who just want to encrypt or decrypt things.
The scope of the package is to protect data that has been saved to disk. It is not designed to stop an attacker targeting the R process itself to determine the contents of sensitive data. The package does try to prevent you accidentally saving to disk the contents of sensitive information, including the keys that could decrypt such information.
This vignette works through the basic functionality of the package. It does not offer much in the way of an introduction to encryption itself; for that see the excellent vignettes in the openssl
and sodium
packages (see vignette("crypto101")
and vignette("bignum")
for information about how encryption works). This package is a wrapper around those packages in order to make them more accessible.
To encrypt anything we need a key. There are two sorts of key “types” we will concern ourselves with here “symmetric” and “asymmetric”.
“symmetric” keys are used for storing secrets that multiple people need to access. Everyone has the same key (which is just a bunch of bytes) and with that we can either encrypt data or decrypt it.
a “key pair” is a public and a private key; this is used in communication. You hold a private key that nobody else ever sees and a public key that you can copy around all over the show. These can be used for a couple of different patterns of communication (see below).
We support symmetric keys and asymmetric key pairs from the openssl
and sodium
packages (which wrap around industry-standard cryptographic libraries) - this vignette will show how to create and load keys of different types as they’re used.
The openssl
keys have the advantage of a standard key format, and that many people (especially on Linux and macOS) have a keypair already (see below if you’re not sure if you do). The sodium
keys have the advantage of being a new library, starting from a clean slate rather than carrying with it accumulated ideas from the last 20 years of development.
The idea in cyphr
is that we can abstract away some differences in the types of keys and the functions that go with them to create a standardised interface to encrypting and decrypting strings, R objects, files and raw vectors. With that, we can then create wrappers around functions that create files and simplify the process of adding encryption into a data workflow.
Below, I’ll describe the sorts of keys that cyphr
supports and in the sections following describe how these can be used to actually do some encryption.
Illustration of Symmetric Encryption
This is the simplest form of encryption because everyone has the same key (like a key to your house or a single password). This raises issues (like how do you store the key without other people reading it) but we can deal with that below.
openssl
To generate a key with openssl
, you can use:
which generates a raw vector
## aes 57:7f:c1:b3:ff:6e:f6:6b:87:58:b0:f1:aa:9e:d2:2b
(this prints nicely but it really is stored as a 16 byte raw vector).
The encryption functions that this key supports are openssl::aes_cbc_encrypt
, openssl::aes_ctr_encrypt
and openssl::aes_gcm_encrypt
(along with the corresponding decryption functions). The cyphr
package tries to abstract this away by using a wrapper `cyphr::key_openssl
## <cyphr_key: openssl>
With this key, one can encrypt a string with cyphr::encrypt_string
:
and decrypt it again with cyphr::decrypt_string
:
## [1] "my secret string"
See below for more functions that use these key objects.
sodium
The interface is almost identical using sodium symmetric keys. To generate a symmetric key with libsodium you would use sodium::keygen
This is really just a raw vector of length 32, without even any class attribute!
The encryption functions that this key supports are sodium::data_encrypt
and sodium::data_decrypt
. To create a key for use with cyphr
that knows this, use:
## <cyphr_key: sodium>
This key can then be used with the high-level cyphr encryption functions described below.
Illustration of Asymmetric Encryption
With asymmetric encryption everybody has two keys that differ from everyone else’s key. One key is public and can be shared freely with anyone you would like to communicate with and the other is private and must never be disclosed.
In the sodium
package there is a vignette (vignette("crypto101")
) that gives a gentle introduction to how this all works. In practice, you end up creating a pair of keys for yourself. Then to encrypt or decrypt something you encrypt messages with the recipient’s public key and they (and only they) can decrypt it with their private key.
One use for asymmetric encryption is to encrypt a shared secret (such as a symmetric key) - with this you can then safely store or communicate a symmetric key without disclosing it.
openssl
Let’s suppose that we have two parties “Alice” and “Bob” who want to talk with one another. For demonstration purposes we need to generate SSH keys (with no password) in temporary directories (to comply with CRAN policies). In a real situation these would be on different machines (Alice has no access to Bob’s key!) and these keys would be password protected.
path_key_alice <- cyphr::ssh_keygen(password = FALSE)
path_key_bob <- cyphr::ssh_keygen(password = FALSE)
Note that each directory contains a public key (id_rsa.pub
) and a private key (id_rsa
).
## [1] "id_rsa" "id_rsa.pub"
## [1] "id_rsa" "id_rsa.pub"
Below, the full path to the key (e.g., .../id_rsa
) could be used in place of the directory name if you prefer.
If Alice wants to send a message to Bob she needs to use her private key and his public key
## <cyphr_keypair: openssl>
with this pair she can write a message to “bob”:
The secret is now just a big pile of bytes
## [1] 58 0a 00 00 00 03 00 04 02 00 00 03 05 00 00 00 00 05 55 54 46 2d 38 00 00
## [26] 02 13 00 00 00 04 00 00 00 18 00 00 00 10 d9 c6 b7 e2 1c fd cc a9 39 a6 5e
## [51] 6e 4f 12 5a 8b 00 00 00 18 00 00 01 00 09 20 72 03 ec 7f af 0f d7 da 84 f8
## [76] 3f 0f f9 3f 28 02 2f ee 47 c1 c7 55 ac 15 93 9f 1e da 56 e1 d7 80 8b 0c e0
## [101] d8 a3 84 32 24 3c 0c b3 db 5a 58 c5 56 2a da 2c 72 77 cd 9d 2f fe 20 a8 7e
## [126] e7 2c 7a ce 72 57 74 01 91 3e 6e ff 39 d8 96 67 61 9c cb f8 e4 08 c6 42 c7
## [151] d7 90 6f ae 0a b0 56 43 c2 ff 4d e4 99 e6 79 d7 54 89 da 31 65 85 a5 68 64
## [176] 6d 2d dc 51 48 9b 22 6c ba 45 1d 0d 23 53 43 20 98 27 20 fb b0 b2 74 e5 a5
## [201] 1e b6 05 62 e2 7d 26 73 2c 18 a2 38 c3 2f 79 ca e0 5f a4 67 31 cd fa e9 89
## [226] 6f ea 53 4d 7a a3 9f f3 e1 eb fc 7f d0 a1 89 86 2e 55 23 97 25 06 a0 76 f6
## [251] 8e f9 92 db 55 9d 13 ef b5 5c e0 98 13 19 39 f0 69 b9 69 6a b8 37 f3 0a 41
## [276] 7a da 26 8c 08 52 e5 38 73 4a af d6 e7 b8 1d f8 8e 66 ea 81 9b f4 8f d9 77
## [301] e3 9a 91 e4 f4 55 76 ef 9d 1f 44 ce c9 5b 64 aa 64 69 8a 00 00 00 18 00 00
## [326] 00 10 35 d6 e7 16 0c c2 56 9e 8c 27 b7 49 f2 0d b1 9e 00 00 00 18 00 00 01
## [351] 00 61 c8 95 d3 26 68 1a d0 26 34 bf 14 5e 47 af c2 49 08 b6 77 69 31 26 53
## [376] c9 03 e8 dd 30 a4 f7 20 c5 fc 2d c0 7e cb 4d f5 30 44 0e 65 6d 22 4b 06 4a
## [401] 88 58 e9 2f ca 57 bc 22 dc 30 b9 9c a6 cc 68 82 c1 3a 03 2a 36 8f f6 da 15
## [426] ed 61 c9 07 3c e6 52 84 29 2e 03 32 c4 53 11 ed 94 a4 11 6c 0c 4c 97 84 63
## [451] 76 b4 81 c4 42 4a d8 b3 46 cf f6 07 eb 5c 5d a5 b8 28 59 91 1a 32 4d a0 a9
## [476] 33 81 7e 17 83 73 b4 44 eb 8c b8 52 ff eb 68 f5 b0 cb c2 db 40 43 e2 5b b1
## [501] 64 16 c6 af bb a6 4c 53 03 ff 0c 0a 92 37 f2 a8 48 14 2c a4 f7 4a 48 0a 2a
## [526] bb e2 0e 03 2e fd ad ab b3 2a 92 98 ca c6 d0 c8 0e a9 21 e0 4f d9 34 f5 0b
## [551] 16 ec 90 f5 ed ba ed 07 93 a3 3f 7b 3b 92 85 2d e7 a7 10 f9 da de 61 53 bd
## [576] 6b ce 24 83 a3 29 76 f3 78 b6 0e 6b a0 2e 92 8b fe 22 03 9c 7b 5b a8 d6 1b
## [601] 52 92 29 36 b2 3d 02 00 00 04 02 00 00 00 01 00 04 00 09 00 00 00 05 6e 61
## [626] 6d 65 73 00 00 00 10 00 00 00 04 00 04 00 09 00 00 00 02 69 76 00 04 00 09
## [651] 00 00 00 07 73 65 73 73 69 6f 6e 00 04 00 09 00 00 00 04 64 61 74 61 00 04
## [676] 00 09 00 00 00 09 73 69 67 6e 61 74 75 72 65 00 00 00 fe
Note that unlike symmetric encryption above, Alice cannot decrypt her own message:
## Error: OpenSSL error in RSA_padding_check_PKCS1_type_2: pkcs decoding error
For Bob to read the message, he uses his private key and Alice’s public key (which she has transmitted to him previously).
With this keypair, Bob can decrypt Alice’s message
## [1] "secret message"
And send one back of his own:
## [1] 58 0a 00 00 00 03 00 04 02 00 00 03 05 00 00 00 00 05 55 54 46 2d 38 00 00
## [26] 02 13 00 00 00 04 00 00 00 18 00 00 00 10 11 1e 33 d4 55 eb 64 4f f2 37 70
## [51] f2 21 1e b3 89 00 00 00 18 00 00 01 00 0a d8 a4 1d 8e 97 17 44 6a 0a 5b 34
## [76] e6 5d 5a 6f 4d 9b af 56 2e c0 50 35 91 78 8d 8c 68 21 b4 6b 37 53 0d 02 58
## [101] 8a 8d d3 53 7f 51 e3 4b b3 87 b9 ad 0f 80 39 2e 78 5c 4f f5 0f 71 82 f8 ea
## [126] bb a6 9d 6f 39 75 4b 2b af e1 4a 97 ba ca 3d 01 78 ac d8 13 8e 17 b5 a6 ae
## [151] b7 70 81 ba 45 58 9e fd ce 31 23 50 f5 93 33 bf 88 02 3d 3d f0 9f 3f f4 3f
## [176] 6f fe 37 50 40 8f 9b 5f 05 c6 c7 a7 a9 1a 63 da 66 f9 06 25 11 c4 9a 3d 74
## [201] d5 68 b0 d3 d6 6a 30 d0 71 07 91 0e ab c4 72 37 c1 84 0d 80 2c fe 8d 79 99
## [226] b0 b0 1f ff 0a 49 8b c1 87 31 d0 cf 9c e7 3f 6e 68 ab 00 a1 53 1e c3 c5 60
## [251] 83 7b 09 ef d5 9b 93 c0 6d 53 b2 41 e6 4f 10 35 78 c5 8a ef de 67 61 26 6b
## [276] 49 e3 58 9a 2e 0f a2 42 32 3c 3f 77 40 87 00 d2 af 95 57 a2 14 10 46 90 e0
## [301] c0 92 03 97 79 ce a2 1b d7 1e 8f 8a b2 f6 88 7d 65 fa be 00 00 00 18 00 00
## [326] 00 10 01 d4 f0 ad c6 0b fa 0b 5a 72 80 91 89 7e 3c b9 00 00 00 18 00 00 01
## [351] 00 68 fc c4 6f 51 60 d1 a8 80 ec 2d 14 87 51 5b 2f 6a 14 fd be 45 bf bd df
## [376] b7 af 92 9a 53 72 ac 65 df 38 ab c1 13 ee d1 e3 33 9a 72 06 ba 46 01 fa 4e
## [401] fc 90 fe 78 51 53 8c 30 1b 5a 98 7e ee 96 ae 4d 0c d6 9f 32 ba 37 8b f3 c9
## [426] 97 e4 18 c5 c4 4d e9 db 4d 2d d1 ac dc 44 ac f6 99 8b 29 31 c3 1b 85 01 f3
## [451] 0c ce 8b c6 65 a7 81 a8 0b 2d 68 37 e4 e8 06 51 32 63 03 04 4f ce d2 9f 20
## [476] 8d c7 27 5e a2 85 33 62 7c 9d 65 a4 d8 f2 ee 1a 7e 6d ec cf 27 3a bc 13 e3
## [501] 4e bb 0b 99 0f 81 a7 ee 55 f8 df f9 5c 9e 6f 39 8e d2 d4 3f 01 c4 a3 44 b6
## [526] 92 ea 15 fc 5b a5 04 85 20 b6 97 b4 91 c7 48 e2 cf 5f 45 98 4d 73 ec d5 00
## [551] 10 cc 47 6b c0 b3 72 cb 11 f4 b6 02 47 56 a5 c3 12 14 c4 7d 48 d1 a0 1f d2
## [576] 59 99 1d fd 37 4e 40 6e 9d 0e b5 c0 2f b4 4b a6 bb e5 cd ff 67 ce eb a4 d0
## [601] a6 d5 92 fa de 38 14 00 00 04 02 00 00 00 01 00 04 00 09 00 00 00 05 6e 61
## [626] 6d 65 73 00 00 00 10 00 00 00 04 00 04 00 09 00 00 00 02 69 76 00 04 00 09
## [651] 00 00 00 07 73 65 73 73 69 6f 6e 00 04 00 09 00 00 00 04 64 61 74 61 00 04
## [676] 00 09 00 00 00 09 73 69 67 6e 61 74 75 72 65 00 00 00 fe
which she can decrypt
## [1] "another message"
Chances are, you have an openssl keypair in your .ssh/
directory. If so, you would pass NULL
as the path for the private (or less usefully, the public) key pair part. So to send a message to Bob, we’d include the path to Bob’s public key.
This all skips over how Alice and Bob will exchange this secret information. Because the secret is bytes, it’s a bit odd to work with. Alice could save the secret to disk with
secret <- cyphr::encrypt_string("secret message", pair_a)
path_for_bob <- file.path(tempdir(), "for_bob_only")
writeBin(secret, path_for_bob)
And then send Bob the file for_bob_only
(over email or any other insecure medium).
and bob could read the secret in with:
secret <- readBin(path_for_bob, raw(), file.size(path_for_bob))
cyphr::decrypt_string(secret, pair_b)
## [1] "secret message"
As an alternative, you can “base64 encode” the bytes into something that you can just email around:
## [1] "WAoAAAADAAQCAAADBQAAAAAFVVRGLTgAAAITAAAABAAAABgAAAAQbnWrl0FWC7cjNZLqVPU8HQAAABgAAAEAG+iC89U7rCkkYXwYESxO24ziH6npKMhTTVpK54EGI/tODo8ep3geunw5dRq5llXFkcO1PrS3rLQ+l3tZblCdMEoi24+QXEfryqS2mG9MjPJnAYJTgJF4mdUP9NHrxD7a/N4UIEpfaTbxM5OEdcDS/wQluJbASimOMtf+RM9CPucIbxBxJ1Dk0qCi0J/Wkx7pfrHL1JuqiZxQn0gpillH6cpHwhPOlzYj4+EPiz9AYi+IuWMZIlk9zlroBUoJ3asjo99Qvu9pZtfIWHcIudauZ24+uJX6fb3z+bmltYGt6k3JkQFLQQcoG2ZGecbyfbGvR4ckJUNSygFBkovpJc7L1AAAABgAAAAQtZi2LW9719NMr+E7SeVpYAAAABgAAAEAYciV0yZoGtAmNL8UXkevwkkItndpMSZTyQPo3TCk9yDF/C3AfstN9TBEDmVtIksGSohY6S/KV7wi3DC5nKbMaILBOgMqNo/22hXtYckHPOZShCkuAzLEUxHtlKQRbAxMl4RjdrSBxEJK2LNGz/YH61xdpbgoWZEaMk2gqTOBfheDc7RE64y4Uv/raPWwy8LbQEPiW7FkFsavu6ZMUwP/DAqSN/KoSBQspPdKSAoqu+IOAy79rauzKpKYysbQyA6pIeBP2TT1CxbskPXtuu0Hk6M/ezuShS3npxD52t5hU71rziSDoyl283i2DmugLpKL/iIDnHtbqNYbUpIpNrI9AgAABAIAAAABAAQACQAAAAVuYW1lcwAAABAAAAAEAAQACQAAAAJpdgAEAAkAAAAHc2Vzc2lvbgAEAAkAAAAEZGF0YQAEAAkAAAAJc2lnbmF0dXJlAAAA/g=="
This can be converted back with openssl::base64_decode
:
## [1] TRUE
Or, less compactly but also suitable for email, you might just convert the bytes into their hex representation:
## [1] "580a000000030004020000030500000000055554462d38000002130000000400000018000000106e75ab9741560bb7233592ea54f53c1d00000018000001001be882f3d53bac2924617c18112c4edb8ce21fa9e928c8534d5a4ae7810623fb4e0e8f1ea7781eba7c39751ab99655c591c3b53eb4b7acb43e977b596e509d304a22db8f905c47ebcaa4b6986f4c8cf26701825380917899d50ff4d1ebc43edafcde14204a5f6936f133938475c0d2ff0425b896c04a298e32d7fe44cf423ee7086f10712750e4d2a0a2d09fd6931ee97eb1cbd49baa899c509f48298a5947e9ca47c213ce973623e3e10f8b3f40622f88b9631922593dce5ae8054a09ddab23a3df50beef6966d7c8587708b9d6ae676e3eb895fa7dbdf3f9b9a5b581adea4dc991014b4107281b664679c6f27db1af478724254352ca0141928be925cecbd40000001800000010b598b62d6f7bd7d34cafe13b49e56960000000180000010061c895d326681ad02634bf145e47afc24908b67769312653c903e8dd30a4f720c5fc2dc07ecb4df530440e656d224b064a8858e92fca57bc22dc30b99ca6cc6882c13a032a368ff6da15ed61c9073ce65284292e0332c45311ed94a4116c0c4c97846376b481c4424ad8b346cff607eb5c5da5b82859911a324da0a933817e178373b444eb8cb852ffeb68f5b0cbc2db4043e25bb16416c6afbba64c5303ff0c0a9237f2a848142ca4f74a480a2abbe20e032efdadabb32a9298cac6d0c80ea921e04fd934f50b16ec90f5edbaed0793a33f7b3b92852de7a710f9dade6153bd6bce2483a32976f378b60e6ba02e928bfe22039c7b5ba8d61b52922936b23d02000004020000000100040009000000056e616d6573000000100000000400040009000000026976000400090000000773657373696f6e00040009000000046461746100040009000000097369676e6174757265000000fe"
and the reverse with sodium::hex2bin
:
## [1] TRUE
(this is somewhat less space efficient than base64 encoding.
As a final option, you can just save the secret with saveRDS
and read it in with readRDS
like any other option. This will be the best route if the secret is saved into a more complicated R object (e.g., a list or data.frame
).
See the other cyphr vignette (vignette("data", package = "cyphr")
) for a suggested workflow for exchanging secrets within a team, and the wrapper functions below for more convenient ways of working with encrypted data.
Do you already have an ssh keypair? To find out, run
One of three things will happen:
you will be prompted for your password to decrypt your private key, and then after entering it an object <cyphr_keypair: openssl>
will be returned - you’re good to go!
you were not prompted for your password, but got a <cyphr_keypair: openssl>
object. You should consider whether this is appropriate and consider generating a new keypair with the private key encrypted. If you don’t then anyone who can read your private key can decrypt any message intended for you.
you get an error like Did not find default ssh public key at ~/.ssh/id_rsa.pub
. You need to create a keypair.
To create a keypair, you can use the cyphr::ssh_keygen()
function as
This will create the keypair as ~/.ssh/id_rsa
and ~/.ssh/id_rsa.pub
, which is where cyphr
will look for your keys by default. See ?ssh_keygen
for more information. (On Linux and macOS you might use the ssh-keygen
command line utility. On windows, PuTTY` has a utility for creating keys.)
sodium
With sodium
, things are largely the same with the exception that there is no standard format for saving sodium keys. The bits below use an in-memory key (which is just a collection of bytes) but these can also be filenames, each of which contains the contents of the key written out with writeBin
.
First, generate keys for Alice:
the public key is derived from the private key, and Alice can share that with Bob. We next generate Bob’s keys
Bob would now share is public key with Alice.
If Alice wants to send a message to Bob she again uses her private key and Bob’s public key:
As above, she can now send a message:
## [1] 9f 81 d4 8f 13 a2 b6 d9 15 72 97 27 44 da 2f a3 da 2b 38 ad a9 58 93 99 4c
## [26] b2 fc cb 11 56 39 73 bb 60 63 98 28 75 7f 23 d9 08 9e 56 c5 2e 5e 08 c3 54
## [51] 13 e7 19 84
Note how this line is identical to the one in the openssl
section.
To decrypt this message, Bob would use Alice’s public key and his private key:
## [1] "secret message"
Above, we used cyphr::encrypt_string
and cyphr::decrypt_string
to encrypt and decrypt a string. There are several such functions in the package that encrypt and decrypt
encrypt_object
/ decrypt_object
(using serialization and deserialization)encrypt_string
/ decrypt_string
encrypt_data
/ decrypt_data
encrypt_file
/ decrypt_file
For this section we will just use a sodium symmetric encryption key
For the examples below, in the case of asymmetric encryption (using either cyphr::keypair_openssl
or cyphr::keypair_sodium
) the sender would use their private key and the recipient’s public key and the recipient would use the complementary key pair.
Here’s an object to encrypt:
This creates a bunch of raw bytes corresponding to the data (it’s not really possible to print this as anything nicer than bytes).
## [1] c7 38 50 bf 70 d5 0d 0d 00 f3 e6 05 64 0a 3f a2 88 57 9b 3a 02 f6 e2 5e 10
## [26] dc 45 37 ef 09 50 d6 64 5d 93 9d f2 0a 72 8e a9 24 85 c4 67 62 3e c7 ab 60
## [51] e8 d1 d5 c0 50 00 f0 30 53 ff da 09 51 c9 86 60 5b 8a e5 89 fc ff 7e 1a 8a
## [76] 00 90 f7 c4 d6 98 80 a6 47 91 63 c5 67 c6 6d 4f 6a 66 61 0a c5 dc 76 5f c0
## [101] 15 32 8c 0e 57 ac ef 3c bf 25 99 1e fa 4b 96 ea 71 d8 6d 15 c2 82 e5 fe ef
## [126] f6 b7 ee 31 2a de a9 e2 3b f8 ba ca 3b 74 3c 4a 1a a0 2a 09 e5 35 f1 f0 c8
## [151] 4c d4 e9 2c ca 50 39 6a ef 99 1d 8f 4d e9 4d ad 52 c6 f7 c5 86 53 e5 12 e9
## [176] e1 b9 b4 51 df 85 3f d1 79 a5 0f 4b 43 9f 16 d2 8d 2e dc 48 de 2c 08 5b 41
## [201] cf bf de 88 39 13 c9 f2 78 b5 ef 2b a9 87 63 12 1d fd e1 fe 19 eb a8 13 c4
## [226] 1f 1d 07 05 a4 86 7a 82 0d 37 43 7d e8 db fb b2 a0 70 dc 92 e4 0e a2 10 18
## [251] 9a f2 3b d9
The data can be decrypted with the decrypt_object
function:
## $x
## [1] 1 2 3 4 5 6 7 8 9 10
##
## $y
## [1] "secret"
Optionally, this process can go via a file, using a third argument to the functions (note that temporary files are used here for compliance with CRAN policies - any path may be used in practice).
There is now a file called secret.rds
in the temporary directory:
## [1] TRUE
though it is not actually an rds file:
## Error in readRDS(path_secret): unknown input format
When passed a filename (as opposed to a raw vector), cyphr::decrypt_object
will read the object in before decrypting it
## $x
## [1] 1 2 3 4 5 6 7 8 9 10
##
## $y
## [1] "secret"
For the case of strings we can do this in a slightly more lightweight way (the above function routes through serialize
/ deserialize
which can be slow and will create larger objects than using charToRaw
/ rawToChar
)
## [1] 62 72 48 a3 50 dd c1 25 5a b1 ff 87 4b e7 3e 0f f2 d6 b1 53 6f 41 c4 66 41
## [26] d7 ae 30 e7 c5 7a 15 2a 92 90 fe dc 91 bf 48 5b 61 6e 21 96 88
and decrypt:
## [1] "secret"
If these are not enough for you, you can work directly with raw objects (bunches of bytes) by using encrypt_data
:
## [1] 47 eb 86 31 2e 60 2c 4d df e7 d6 d4 a5 69 71 43 85 98 6a d9 7a 32 d1 37 6e
## [26] 5f 31 57 6b 04 18 3f 7d 72 e5 64 00 49 64 0c 98 a2 ba 58 a2 30 40 00 91 db
## [51] 2a 8c 49 2b bb 44 16 0b fe 82 06 06 ed 8e f4 73 2b ac ef aa cc 99 c9 fa d5
## [76] 70 56 66 31 ba 68 50 b1 f2 24 0e a8 88 e6 c7 15 eb 70 b4 f1 6b 14 4f 00 27
## [1] 36 86 ec d6 b4 1b 38 ec b7 9a 0c b6 aa 2d 09 c1 8d ae ce a7 13 c3 08 7f 54
## [26] e9 58 0d 26 37 47 c2 45 38 d1 82 6a 29 66 9a cf 41 46 fc b9 f9 13 c0 d2 9b
## [51] ac d4 14 25 11 f8 3a 76 47 b7 d7 97 83 37 a4 47 7a c0 49 55 12 7c 17 24 1c
## [76] 84 cb a1 72 e3 89 3a f3 e4 5d 80 b3 6c 4f 3c ad 15 fe 70 99 93 ac d1 7b af
## [101] fd 83 97 4f c6 b7 e5 d1 a9 fb f9 28 67 7f 09 ce c4 6e d5 ce 08 be 6e 43 12
## [126] 10 3b db 14 a0 f5 e7 42 2f 8b 4d 9c 32 c3 31
Decrypted data is the same as a the original data
## [1] TRUE
Suppose we have written a file that we want to encrypt to send to someone (in a temporary directory for compliance with CRAN policies)
You can encrypt that file with
path_data_enc <- file.path(tempdir(), "iris.csv.enc")
cyphr::encrypt_file(path_data_csv, key, path_data_enc)
This encrypted file can then be decrypted with
path_data_decrypted <- file.path(tempdir(), "idis2.csv")
cyphr::decrypt_file(path_data_enc, key, path_data_decrypted)
Which is identical to the original:
## /tmp/RtmpI8wXy7/iris.csv /tmp/RtmpI8wXy7/idis2.csv
## "5fe92fe6a2c1928ef5a67b8939fdaf8d" "5fe92fe6a2c1928ef5a67b8939fdaf8d"
This is the most user-friendly way of using the package when the aim is to encrypt and decrypt files. The package provides a pair of functions cyphr::encrypt
and cyphr::decrypt
that wrap file writing and file reading functions. In general you would use encrypt
when writing a file and decrypt
when reading one. They’re designed to be used like so:
Suppose you have a super-secret object that you want to share privately
If you save x
to disk with saveRDS
it will be readable by everyone until it is deleted. But if you encrypted the file that saveRDS
produced it would be protected and only people with the key can read it:
(see below for some more details on how this works).
This file cannot be read with readRDS
:
## Error in readRDS(path_object): unknown input format
but if we wrap the call with decrypt
and pass in the config object it can be decrypted and read:
## $a
## [1] 1 2 3 4 5 6 7 8 9 10
##
## $b
## [1] "don't tell anyone else"
What happens in the call above is cyphr
uses “non standard evaluation” to rewrite the call above so that it becomes (approximately)
cyphr::decrypt_file
to decrypt “secret.rds” as a temporary filereadRDS
on that temporary fileThis non-standard evaluation breaks referential integrity (so may not be suitable for programming). You can always do this manually with encrypt_file
/ decrypt_file
so long as you make sure to clean up after yourself.
The encrypt
function inspects the call in the first argument passed to it and works out for the function provided (saveRDS
) which argument corresponds to the filename (here "secret.rds"
). It then rewrites the call to write out to a temporary file (using tempfile()
). Then it calls encrypt_file
(see below) on this temporary file to create the file asked for ("secret.rds"
). Then it deletes the temporary file, though this will also happen in case of an error in any of the above.
The decrypt
function works similarly. It inspects the call and detects that the first argument represents the filename. It decrypts that file to create a temporary file, and then runs readRDS
on that file. Again it will delete the temporary file on exit.
The functions supported via this interface are:
readLines
/ writeLines
readRDS
/ writeRDS
read
/ save
read.table
/ write.table
read.csv
/ read.csv2
/ write.csv
read.delim
/ read.delim2
But new functions can be added with the rewrite_register
function. For example, to support the excellent rio package, whose import
and export
functions take the filename file
you could use:
now you can read and write tabular data into and out of a great many different file formats with encryption with calls like
The functions above use non standard evaluation and so may not be suitable for programming or use in packages. An “escape hatch” is provided via encrypt_
and decrypt_
where the first argument is a quoted expression.
cyphr::encrypt_(quote(saveRDS(x, path_object)), key)
cyphr::decrypt_(quote(readRDS(path_object)), key)
## $a
## [1] 1 2 3 4 5 6 7 8 9 10
##
## $b
## [1] "don't tell anyone else"
When using key_openssl
, keypair_openssl
, key_sodium
, or keypair_sodium
we generate something that can decrypt data. The objects that are returned by these functions can encrypt and decrypt data and so it is reasonable to be concerned that if these objects were themselves saved to disk your data would be compromised.
To avoid this, cyphr
does not store private or symmetric keys directly in these objects but instead encrypts the sensitive keys with a cyphr
-specific session key that is regenerated each time the package is loaded. This means that the objects are practically only useful within one session, and if saved with save.image
(perhaps automatically at the end of a session) the keys cannot be used to decrypt data.
To manually invalidate all keys you can use the cyphr::session_key_refresh
function. For example, here is a symmetric key:
which we can use to encrypt a secret string
and decrypt it:
## [1] "my secret"
If we refresh the session key we invalidate the key
object
and after this point the key cannot be used any further
## Error: Failed to decrypt key as session key has changed
This approach works because the package holds the session key within its environment (in cyphr:::session$key
) which R will not serialize. As noted above - this approach does not prevent an attacker with the ability to snoop on your R session from discovering your private keys or sensitive data but it does prevent accidentally saving keys in a way that would be useful for an attacker to use in a subsequent session.
openssl
(vignette(package = "openssl")
) and sodium
(vignette(package = "openssl")
) packages have explanations of how the tools used in cyphr
work and interface with R.Confused? Need help? Found a bug?
cyphr
issue trackerThese binaries (installable software) and packages are in development.
They may not be fully stable and should be used with caution. We make no claims about them.