Using this library..
https://github.com/motdotla/dotenv
I've added a private RSA key to .env. Using it to sign a JWT.
When I sign the JWT, this error greats me.
error:0906D066:PEM routines:PEM_read_bio:bad end line
My RSA key is just a basic multi line, key.
-----BEGIN RSA PRIVATE KEY-----
MIIEpgIBAAKCAQE.......
........
The RSA key is multi-line.
DotEnv can only read one-liners, the unfortunate work around (AFIAK) are to add a \n to the end of every line. And then make this string a one liner. But this error keeps occuring..
Has anyone else experienced this and have solution?
Or perhaps know of another env file manager that can handle multi-lines?
Add surrounding double quotes to the value in the .env file and replace line breaks with \n like so:
KEY="-----BEGIN RSA PRIVATE KEY-----\nMIIE..."
Related
I have a next.js application where I have a local .pem file for JWT public/private key authentication. My host does not allow me to upload secret files, so I am trying to access the .pem from a muli-line string .env variable.
I have the contents of the .pem stored like this:
PUB_KEY="-----BEGIN RSA PUBLIC KEY----- [newline]
YTuFE/BOU+pF6T2nYuyYQugqJHUZ62b3LJAeZYyBIjW+LZLeHGkUOZfqHnwSbmd9[newline]
isMbGtdNN/wujOftX1GSDApHX0LyNb+covtN4X4mcFFqyKuotFftUjOLzvb2AeJe[newline]
s9285pXbhAKVcStyAn26pI5...[newline]
-----END RSA PUBLIC KEY-----"
I get the error: Error, secretOrPrivateKey must be an asymmetric key when using RS256
I have tried to convert the .env variable from a multi line string to a single line string, preserving the newlines with this function:
function makeSingleLineKey(key) {
return key.replace(/(\r\n|\n|\r)/gm, '\\n');
}
but I get the same error.
There is an issue with the formatting of the .pem key I think.
Any ideas what might be going wrong?
Thanks
I was able to fix this by storing the .pem files in .env variables where the multi line strings were converted to a single line with the \n line breaks preserved e.g.
`LOCAL_AUTH_PUB_KEY={"PUB_KEY":"-----BEGIN RSA PUBLIC KEY-----\nMIICCgKCAgEAyLKk4ldt/a9dItmU2GkCVUJ1nTIh137JLTGLVyfPHkBaEBpMSm0j\nYT...`
I then accessed the variables in my code like this:
const { PUB_KEY } = JSON.parse(process.env.LOCAL_AUTH_PUB_KEY)
https://dev.to/cfofiu/how-to-store-a-long-private-key-in-vercel-s-environment-variables-46f5
I am trying to solve the CTF challenges at overthewire and have completed up to 16 levels
To get from level 16 to 17 you have to send the password of the current level to the port supporting SSL on localhost after submitting the password an ssh private key is given to log to the next level
I have done up to here and have successfully got the ssh key save it in a text file changed permission to 600 but whenever I am trying to use this key to log in to the next level I am prompted to give the passphrase for the key I have been stuck here for a long time how I can provide the passphrase since while creating the key there was nothing to set the passphrase
When you send the correct password, you should get the following key:
-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEAvmOkuifmMg6HL2YPIOjon6iWfbp7c3jx34YkYWqUH57SUdyJ
imZzeyGC0gtZPGujUSxiJSWI/oTqexh+cAMTSMlOJf7+BrJObArnxd9Y7YT2bRPQ
Ja6Lzb558YW3FZl87ORiO+rW4LCDCNd2lUvLE/GL2GWyuKN0K5iCd5TbtJzEkQTu
DSt2mcNn4rhAL+JFr56o4T6z8WWAW18BR6yGrMq7Q/kALHYW3OekePQAzL0VUYbW
JGTi65CxbCnzc/w4+mqQyvmzpWtMAzJTzAzQxNbkR2MBGySxDLrjg0LWN6sK7wNX
x0YVztz/zbIkPjfkU1jHS+9EbVNj+D1XFOJuaQIDAQABAoIBABagpxpM1aoLWfvD
KHcj10nqcoBc4oE11aFYQwik7xfW+24pRNuDE6SFthOar69jp5RlLwD1NhPx3iBl
J9nOM8OJ0VToum43UOS8YxF8WwhXriYGnc1sskbwpXOUDc9uX4+UESzH22P29ovd
d8WErY0gPxun8pbJLmxkAtWNhpMvfe0050vk9TL5wqbu9AlbssgTcCXkMQnPw9nC
YNN6DDP2lbcBrvgT9YCNL6C+ZKufD52yOQ9qOkwFTEQpjtF4uNtJom+asvlpmS8A
vLY9r60wYSvmZhNqBUrj7lyCtXMIu1kkd4w7F77k+DjHoAXyxcUp1DGL51sOmama
+TOWWgECgYEA8JtPxP0GRJ+IQkX262jM3dEIkza8ky5moIwUqYdsx0NxHgRRhORT
8c8hAuRBb2G82so8vUHk/fur85OEfc9TncnCY2crpoqsghifKLxrLgtT+qDpfZnx
SatLdt8GfQ85yA7hnWWJ2MxF3NaeSDm75Lsm+tBbAiyc9P2jGRNtMSkCgYEAypHd
HCctNi/FwjulhttFx/rHYKhLidZDFYeiE/v45bN4yFm8x7R/b0iE7KaszX+Exdvt
SghaTdcG0Knyw1bpJVyusavPzpaJMjdJ6tcFhVAbAjm7enCIvGCSx+X3l5SiWg0A
R57hJglezIiVjv3aGwHwvlZvtszK6zV6oXFAu0ECgYAbjo46T4hyP5tJi93V5HDi
Ttiek7xRVxUl+iU7rWkGAXFpMLFteQEsRr7PJ/lemmEY5eTDAFMLy9FL2m9oQWCg
R8VdwSk8r9FGLS+9aKcV5PI/WEKlwgXinB3OhYimtiG2Cg5JCqIZFHxD6MjEGOiu
L8ktHMPvodBwNsSBULpG0QKBgBAplTfC1HOnWiMGOU3KPwYWt0O6CdTkmJOmL8Ni
blh9elyZ9FsGxsgtRBXRsqXuz7wtsQAgLHxbdLq/ZJQ7YfzOKU4ZxEnabvXnvWkU
YOdjHdSOoKvDQNWu6ucyLRAWFuISeXw9a/9p7ftpxm0TSgyvmfLF2MIAEwyzRqaM
77pBAoGAMmjmIJdjp+Ez8duyn3ieo36yrttF5NSsJLAbxFpdlc1gvtGCWW+9Cq0b
dxviW8+TFVEBl1O4f7HVm6EpTscdDxU+bCXWkfjuRb7Dy9GOtt9JPsX8MBTakzh3
vBgsyi/sN3RqRBcGU40fOoZyfAMT8s1m/uYv52O6IgeuZ/ujbjY=
-----END RSA PRIVATE KEY-----
You should copy this to your local computer, and save it as a file called bandit.key (name doesn't really matter). Then you should chmod 600 bandit.key, then ssh with the keyfile with the command:
ssh -i bandit.key bandit17#bandit.labs.overthewire.org -p 2220
Which should log you in.
I almost lost it with this one, but just logged in, had the same problem as the author, tried changing it to chmod 400 then 600 still had the same problem. What worked was copying the the key from the comment above, I suspect the "<" symbol in front of every line when copying from the terminal was somehow interfering with this.
I've got a .env file with public/private multiline keys in it, but only some keys are parsing. While the PUBLIC_KEY variable parses correctly with the dotenv package, PRIVATE_KEY is parsed as '-----BEGIN RSA PRIVATE KEY-----.
We've tried swapping their positions in the file, swapping their values, but nothing we do changes the way the file parses--regardless of how we change the file, the PUBLIC_KEY alone parses correctly.
PUBLIC_KEY='-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAuEdNotdGbDKZO1o7oATA
...
BvnP5uVCRrHigT1b8kvpJ/ptVw3hy2yE9h6V0Lolqq8XJ4kydLrOym5fVCdQlGBV
a9R7j5Z/03IUU34BwHNy648CAwEAAQ==
-----END PUBLIC KEY-----
'
PRIVATE_KEY='-----BEGIN RSA PRIVATE KEY-----
MIIJKQIBAAKCAgEAuEdNotdGbDKZO1o7oATAn6PsIoN3DhVLAZBDjg2JZ54ZDVc/
...
jUId69Z3cNk9QM2q0y26qo8uhEZ+yHCkxC3tBfWJ45YrP+Mj3FsPR044rhmu
-----END RSA PRIVATE KEY-----
'
We've got a working solution to manually input line breaks into the remaining keys, but we're still curious if anyone knows what could be causing this.
Thank you!
How can I safely store sensitive data online?
I want to store some extremely sensitive information online in a public folder, and I'm not sure how to go about it.
Specifically, I want to store bitcoin private keys in a .json file named "walletData.json" in a public folder. The file contains the wallet address and public key in plain text, along with an encrypted version of the private key.
Assuming anyone can access the file and attempt to crack the encryption password with their "super computers", what's the best way to safely encrypt that private key?
I know a longer password would be a good start, but ideally I don't want to need a password longer than 10 characters.
I was thinking of maybe hashing the password 1000 times, then using that hash+password as an AES encryption key. But, as everyone can see the key generation method, i'm not sure that will help? I was also thinking of padding out the encrypted private key with some other random data, but again, I don't know if it'll really help??
Is there a safe way to do this?
EDIT - after Reid's answer:
I'm trying to do this 100% in Javascript/jQuery.
When I export a CoinPrism.com wallet, I get this:
{"keys":[{"addr":"1PNLiLgW2fBokCB2wmfhZTtbmioitkqtMm","priv":"172655af193edeb54467a52fc6eb94c67eeeff8cd03555767e5cf12df694bb88f9c8b25c4019147d9e4993405274c96a","encryptionMode":"PKBDF2-SHA256","iterations":2000}],"salt":"2222b67fc7255aaf0b4027bfcabffb5e62f39e9e0aa13e8ad70f2dc75a484f26"}
The "priv" value is an encrypted private key. I don't know exactly how it's encrypted, but i'm sure that there's a way to decrypt it using just my 10 character password.
Does anyone know how they're doing this?
Is it safe to store this information online?
Well, I will just say outright that you don't need to be the one who writes the code to do this — it is far too easy to mess up, and your post makes suggestions that are concerning. (For instance, you describe something of an ad-hoc key derivation scheme, but one that is insufficient in protection.)
So, you need a library of some kind to handle this business for you.
My suggestion: Use GPG with the ASCII armor option. For example:
gpg --symmetric --armor --cipher-algo AES file.txt
This will symmetrically encrypt (--symmetric) a file (file.txt here) using the AES cipher (--cipher-algo AES) and store the resulting encrypted file in an ASCII armored format (--armor). Note: the resulting encrypted file will be stored in the filename plus the extension .asc; e.g., here, it puts the result in file.txt.asc. You can change this with the --output option.
Now, the above command will prompt you for a passphrase — this passphrase needs to be very strong, far more than 10 characters I'm afraid. This is the burden of passphrase-based encryption: you need passphrases that are strong. Ideally, you want a passphrase that is long and complicated, hard-to-guess and hard-to-bruteforce.
Since we are on StackOverflow, you may be looking to automate the passphrase entry (using scripting). To do that, there are several --passphrase related options for GPG. For example,
gpg --batch --passphrase "test" --symmetric --armor --cipher-algo AES file.txt
will use the passphrase test instead of prompting the user. Command line arguments are not safe, however, on a system, so it would be better to use the --passphrase-from-file option, which takes a single file as an argument. The first line of that file is the passphrase to be used.
I am using Botan to create public/private ECDSA keypairs. The public keys that are generated (even on different machines using this code) are very similar... too similar to consider safe I would think. Here is an example of two runs:
-----BEGIN PUBLIC KEY-----
MIIBEzCB7AYHKoZIzj0CATCB4AIBATAsBgcqhkjOPQEBAiEA////////////////
/////////////////////v///C8wRAQgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAEIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHBEEEeb5m
fvncu6xVoGKVzocLBwKb/NstzijZWfKBWxb4F5hIOtp3JqPEZV2k+/wOEQio/Re0
SKaFVBmcR9CP+xDUuAIhAP////////////////////66rtzmr0igO7/SXozQNkFB
AgEBAyIAAneDBKm4ubKbv0hxgzhkh0oAI8WKFTs1Hz/Qqyl6qxzD
-----END PUBLIC KEY-----
-----BEGIN PUBLIC KEY-----
MIIBEzCB7AYHKoZIzj0CATCB4AIBATAsBgcqhkjOPQEBAiEA////////////////
/////////////////////v///C8wRAQgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAEIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHBEEEeb5m
fvncu6xVoGKVzocLBwKb/NstzijZWfKBWxb4F5hIOtp3JqPEZV2k+/wOEQio/Re0
SKaFVBmcR9CP+xDUuAIhAP////////////////////66rtzmr0igO7/SXozQNkFB
AgEBAyIAAtQr5BPT04pk/Ror6uIGRqEKeB8dwIteR8p/r+Nl7hql
-----END PUBLIC KEY-----
I am using X509 encoding to encode the public key. Here's the code to generate the ECDSA keys:
LibraryInitializer init;
AutoSeeded_RNG rng;
EC_Group ecGroup("secp256k1");
ECDSA_PrivateKey key(rng, ecGroup);
Why am I generating such similar public keys? And am I right in assuming that isn't "safe" if multiple users were to use this code to generate their own keys?
UPDATE:
The answer below seems correct. I emailed the creator of XCA, Christian Hohnstaedt, to probe a little further into how XCA generates this public key and what it is. He replied that it is the EC_POINT and is obtained by using the command
openssl ec -pubin -noout -text
Plugging in the X509 PEM encoded public keys indeed reveals different public EC Points. It should be noted (for other newbs like me) that the public EC Points in the answer do no good for another party on their own - the other party needs to know which EC Group is being used, and that's why the X509 PEM encoding is much more helpful than just an EC Point.
The actual public keys from these are:
02:77:83:04:A9:B8:B9:B2:9B:BF:48:71:83:38:64:87
4A:00:23:C5:8A:15:3B:35:1F:3F:D0:AB:29:7A:AB:1C
C3
and
02:D4:2B:E4:13:D3:D3:8A:64:FD:1A:2B:EA:E2:06:46
A1:0A:78:1F:1D:C0:8B:5E:47:CA:7F:AF:E3:65:EE:1A
A5
These are not the same, so there is no apparent reason to worry on that front. The data that is the same is the key meta-data and encoding bumf (which you would expect to be the same for identical format keys).
Values obtained by importing into xca (linux). There are better tools for inspecting DER encoded data, but I couldn't find any easily.