download a pgp key automaticly - linux

I want to download a pgp key from a keyserver automaticly using gpg like this:
gpg --searchkey carol#example.com
gpg is giving me this result.
gpg: searching for "carol#example.com" from hkp server pool.sks-keyservers.net
(1) <carol#example.com>
2048 bit RSA key 2F5E71CD, created: 2015-02-17
Keys 1-1 of 1 for "carol#example.com". Enter number(s), N)ext, or Q)uit >
If I want to add this key to my keyring I need to press "1" and ENTER.
My Question is: Is there a way to insert automatically always the first found key from the keyserver to my keyring? Because if I want to do it with about 200 addresses it would be nice if I can import them by a script without sitting next to the computer and pressing always "1" and Enter.
I know that is a security risk to import automatically always the first key, but to import the keys automatically means not that I also trust them automatically.

Do not use mail addresses for finding keys when scripting. Everybody can upload keys with arbitrary user IDs in them, key servers to not check anything at all. It is even easily possible to calculate short key ID collisions. Trusting arbitrary keys on key servers provides a very, very dangerous, false assumption of safety.
For scripting purpose, always work with key fingerprints. These are secure against collision attacks and provide a unique identifier for OpenPGP keys (in theory, they do not, but they provide a larger key address space than UUIDs do, which in practice are considered unique).
To download a list of fingerprints, use something like
gpg --recv-keys \
0D69E11F12BDBA077B3726AB4E1F799AA4FF2279 \
4AC1999F0BA293E8960AF2DA428C3085AF19CFE9 \
...
(alternatively, remove the backslashes and put everything on a single line)
To simply fetch all keys and validate trust on another way (eg. through the web of trust, but don't forget to do so), you have to script around GnuPG. Here is an example script originally posted on security.SE, which takes a file containing one mail address per line and fetches all matching keys:
#!/bin/sh
while read line
do
gpg --with-colons --batch --search $line 2>/dev/null | \
awk 'BEGIN { FS = ":" }; $1=="pub" { print $2 }' | \
xargs gpg --recv-keys
done < $1

Related

Add two Yubikey to KeepassXC

I'm testing Yubico Yubikeys 5 NFC, in general, we use KeePassXC to save sensible information. KeePassXC accepts yubikeys but just one... Anyone know if it possible to add more than one to a kdbx file?
After talking to the KeePassXC dev team, it is clear that having two different seeds in two separate Yubikeys is not possible. You need to add the same seed to the other Yubikey to keep a copy of the seed.
In the Docs section, can we read this:
What happens if I break my YubiKey? Can I create backup keys?
You should always make a copy of the HMAC secret that is stored on the YubiKey and keep it in a secure location. This can be an analog paper copy, but since the YubiKey personalization tool allows you to program a custom secret into the key, you may as well program a second key with the same secret
Can I register multiple YubiKeys with my KeePassXC database?
You can only use a single secret for encrypting the database. So you can use multiple YubiKeys, but they all have to be programmed with the same secret (see question above).
and The explanation to how to setup the same id in slot 2 in two yubikeys is here:
https://support.yubico.com/hc/en-us/articles/360013779759-Using-Your-YubiKey-with-KeePass
Just remember in the second key you must copy & paste the same seed
The complete discussion is here: https://github.com/keepassxreboot/keepassxc/discussions/6344
Recommend to use a strong master password on top of the YubiKeys & save the DB regularly to generate new challenge/response pairs. Far from perfect but better than just a password. The following method (Challenge-response with HMAC-SHA1) works on Ubuntu with KeePassXC v2.6.2 and 2x YubiKey 5 NFC with firmware v5.4.3:
Install ykman (part of yubikey-manager)
$ sudo apt-get install yubikey-manager
Check that slot#2 is empty in both key#1 and key#2. You will be overwriting slot#2 on both keys.
$ ykman otp info
Slot 1: programmed
Slot 2: empty
Generate a base32-encoded secret seed (ex: "SECRETSEED") that will be programmed into both keys. RFC2104 recommends that your seed is as long as the underlying hash function (20 bytes for SHA1)
$ base32
SECRETSEED<Enter>
CTRL+D
BASE32SECRETSEED
$
Note that the above method adds a CR to the seed. Store SECRETSEED somewhere safe (ideally not digitally) in case you lose both keys
Program the resulting "BASE32SECRETSEED" to key#1 and key#2
$ ykman otp chalresp -t 2
Enter a secret key: BASE32SECRETSEED
Program a challenge-response credential in slot 2? [y/N]: y
Verify the same challenge gives you the same response using both keys
$ ykman otp calculate 2
Enter a challenge (hex): deadbeef
Touch your YubiKey...
aabbccdd11223344556677889900aabbccdd1122
Add one of your keys to your KeePassXC database
Database > Database Security > Add additional protection > Add YubiKey Challenge-Response
Both keys should now work to unlock/save your DB
Refs:
https://developers.yubico.com/Developer_Program/Guides/Touch_triggered_OTP.html
https://github.com/Yubico/python-yubico/blob/master/examples/rolling_challenge_response
https://wiki.archlinux.org/title/YubiKey
https://www.rfc-editor.org/rfc/rfc2104

Stuck on bandit16 level at overthewire

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.

What value of salt should I give to crypt to create a new user on Linux?

I am writing a Perl script which will create a new user (on Ubuntu).
It will need a step along the lines of
$encrypted_password = crypt ($password, $salt);
system ("useradd -d $home -s /bin/bash -g $group -p $encrypted_password $name");
What should the value of $salt be? Examples on the Internet seem to use arbitrary values, but if the encrypted password is going to be tested against what the user enters, then the kernel needs to hash the input with the same salt in order to pass the comparison.
This website claims the salt is encoded in the output of crypt, but that is apparently not true.
In Perl the output of
print crypt("foo", "aa");
print crypt("foo", "aabbcc");
print crypt("foo", "aa1kjhg23gh43jhgk32kh325423g");
print crypt("foo", "abbbcc");
is
aaKNIEDOaueR6
aaKNIEDOaueR6
aaKNIEDOaueR6
abQ9KY.KfrYrc
Aside from there being identical hashes from different salts, which is suspicious, it seems only the first two characters of the salt are used. This does not make sense from a security point of view. Also the output is not in the format as claimed in the link above.
So what value of salt should I use when encrypting a password for useradd?
All the information about crypt is in perldoc -f crypt.
Here is the part that answers your question:
When choosing a new salt create a random two character string whose characters come from the set [./0-9A-Za-z] (like join '', ('.', '/', 0..9, 'A'..'Z', 'a'..'z')[rand 64, rand 64] ). This set of characters is just a recommendation; the characters allowed in the salt depend solely on your system's crypt library, and Perl can't restrict what salts crypt() accepts.
I hope this helps.

Safely storing encrypted sensitive data 'publicly' online?

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.

What is the value of TSS_WELL_KNOWN_SECRET

I want to run a script which calls tpm_sealdata many times and I don't want to enter the SRK password each time.
In the man page I found this:
-z, --well-known
Use TSS_WELL_KNOWN_SECRET (20 zero bytes) as the SRK password.
You will not be prompted for the SRK password with this option.
However, I couldn't figure out which value I have to use as TSS_WELL_KNOWN_SECRET.
As the name of the constant implies, the value of TSS_WELL_KNOWN_SECRET is well known. It is just 20 bytes of zero.
But you don't actually need the value. The -z option does not require a value, it's just a switch to tell the program to use the well known secret. The help text you cite also states this fact.
So a call to tpm_sealdata might look like this:
tpm_sealdata -z -i data.in -o data.out
However, to use this method the SRK must have been created with the well known secret of course. When using tpm_takeownership:
tpm_takeownership -z

Resources