I had setup a working smart card setup, where the local key ring solely contained public subkeys and secret keys resided on a smart card.
Conservatively I set the expiration date to 1 year.
Setup worked nicely and as the keys approached there expiration date, I proceeded as follows to attempt to extend their expiration date:
Kill running gpg-agent:
pkill gpg-agent
Import offline master key (backup):
gpg --import <KEYID>.master.key
Edit expiry of subkeys (pubkey):
gpg --expert --edit-key <KEYID>
toggle keys 1, 2, 3 (sign, encrypt, authentication)
expire: 1y
save
Remove secret master keys:
gpg --delete-secret-keys <KEYID>
As a result the keys remain unavailable (expired?) to all means I intent to use them with (kmail/kgpg/kleopatra, evolution/seahorse, etc.).
Where did I go wrong and how may I recover?
As evident from the comments above, I noted, that the secret keys were (no longer?) listed by gpg --list-secret-keys.
That was remedied by explicitly querying the reader-inserted smart card using gpg --card-status, followed by a now successful gpg --list-secret-keys.
After having pointed evolution at the now available secret key and removing the smart card from its reader, the mail client now (again) asks for insertion of the card when requesting signatures/encryption.
Works again. considered solved.
Related
i've been practicing with the near-cli as part of my personal project to automate some tasks, this requires running near login quite a few times in debugging. However, when i do near login it seems to create a new public key every time, as when I do near keys <account> from time to time I see this list grow. When I did near keys delete <public_key> to cleanup, it did give a warning about accidentally deleting the wrong public key, so I attempted dropping keys older than the last one entered, however running near login again gave an error that I had deleted the key that gave access thru the web login. (I kept the key value and did near keys add <public_key> to restore access.
My question is, how best do I keep track of which public_keys are safe to delete when experimenting with the CLI this way?
The simplest answer is: Make sure you always have one keypair left. Keys are stored in ~/.near-credentials, with files containing both the private and public part of the key. Always keep one of these files, and make you don't remove the corresponding key from the account.
When creating a paper wallet with the solana cli and then running the seed phrase back into the cli I get a completely different pubkey?
What am I missing here?
Not using a passphase in this example.
❯ solana-keygen new --no-outfile
Generating a new keypair
For added security, enter a BIP39 passphrase
NOTE! This passphrase improves security of the recovery seed phrase NOT the
keypair file itself, which is stored as insecure plain text
BIP39 Passphrase (empty for none): none
===============================================================================
pubkey: 7A5h8N21EtjAnfcf8kxp7Bd7pNtQ5SvoYHLyBwz2796e
===============================================================================
Save this seed phrase and your BIP39 passphrase to recover your new keypair:
animal flock border attitude simple piece firm reason snack isolate siege seven
===============================================================================
~/.config/solana
❯ solana-keygen pubkey prompt://
[pubkey recovery] seed phrase:
[pubkey recovery] If this seed phrase has an associated passphrase, enter it now. Otherwise, press ENTER to continue:
2NW5bHw8dh4rS9wZSPj5u6Xec9tCHEN64PiTPUiy2ms7
This is a bit confusing between the BIP44 and BIP39 derivation paths. The seed phrase shown animal flock border attitude simple piece firm reason snack isolate siege seven comes from the legacy derivation, so it should be used with the ASK keyword instead of the prompt:// keyword.
If you want to recover the expected public key, you'll have to run:
$ solana-keygen pubkey ASK
More information found towards the bottom of this section of the docs: https://docs.solana.com/wallet-guide/paper-wallet#public-key-derivation
We are using a custom board based on Beaglebone black (AM335x). To upgrade the board’s firmware, we shall be using an encrypted firmware image.
As you would have already guessed, we will be using symmetric encryption to encrypt a large firmware file (fimware.tar) and then encrypt the symmetric key with an asymmetric key. So we have two files which to give to the user for upgrading his board.
We don’t want to do that; we want to give only one file to each user. So we have to somehow combine the encrypted firmware image and the encrypted symmetric key.
I thought of two strategies. The firmware is encrypted using a bash script.
Tar the encrypted firmware and the encrypted symmetric key.
Problem: This is very slow.
Append the encrypted symmetric key to the encrypted tar file.
Problem: This doesn’t feel like a clean approach, does it?
Are there any better (and faster) ways to handle this?
There are a few ways to do this:
use a well known container format such as OpenPGP or CMS;
pick a less well known / standardized format that happens to confirm to your requirements;
define your own container format.
Option 1 should of course be preferred as this is likely the most secure option. It will also mean you can use standard libraries.
Option 2 requires you to perform research to see if that option fits your needs and is secure.
Option 3 would be a good option if code and format size optimization is a prime concern.
For option 3 you could e.g. use a version / format specifier (1 byte), then the wrapped key (prefixed with a length) and then the firmware (anything after the wrapped key).
My system for ensuring the integrity of a results file produced by my program:
My program does some work appending to results.txt which becomes several gigabytes in size.
My program appends the current-time timestamp to the file.
results.txt is closed.
My program calls gpg --sign --detach results.txt to create a detached signature. This takes several minutes due to the size of results.txt. The pinentry program pops up and the person executing the program is prompted for their secret key passphrase.
Time goes by... The results file is archived...
Much later, in addition to verifying the signature to attribute the file's contents to the signatory, I want to be able to check that the signature was made immediately after the file was closed, to provide assurance that the file was not edited between closing and signing.
When I developed this system using gpg 2.0.17 (libgcrypt 1.5.0) on Ubuntu, I learned that the timestamp to go into the signature was essentially that at the time gpg --sign was called. This worked well, as I could rely on less than 1 second ever elapsed between the timestamp being written to the file and the beginning of gpg signing, much too little time for any manual tampering I think. As part of checking the integrity of the results, I checked that the gpg signature timestamp was less than 1 second after the timestamp written at the end of the file. That worked great, until...
I ported the system to Windows 7 using gpg 2.0.27 (Gpg4win 2.2.4, libgcrypt 1.6.3), and I noticed that in this environment the timestamp to be included in the gpg signature was actually that at the end of gpg signing, or about 2 minutes after the file is closed. This is a long enough period of time to possibly tamper with the file.
Is there a way to ask gpg2 to take the timestamp prior to the actual signature being calculated?
You can enforce a fixed timestamp being used with the --fake-system-time option.
--faked-system-time epoch
This option is only useful for testing; it sets the system time back
or forth to epoch which is the number of seconds elapsed since the
year 1970. Alternatively epoch may be given as a full ISO time string
(e.g. "20070924T154812").
Determine the current time, and pass it to GnuPG when performing the signature operation.
I manage my accounts for websites with KeePass. This tool generates highly complex passwords, such as d,ªL¹(ç,z/¬gSÑ~}ÄwÚÆ¡íµ¯ó]ó6õ?Ô£fß,.
Such a complex password I use for example for Red Hat’s OpenShift website.
OpenShift servers/applications can be managed best by using their rhc command line tool.
Now, while running rhc setup I have to enter my password. So I copy it into the clipboard and paste it into the shell, where rhc sits and waits for my PW. However, the password won’t get accepted.
The process of pasting probably causes some changes. I already tried doing chcp 1252 and chcp 65001 before running rhc setup. Unfortunately this also didn’t help. The only way to get it running was changing my password to a trivial one on the OpenShift website, then doing the setup, and then changing the password back to a complex one.
Anyways, now I want to log in to my applications via rhc ssh, which is asking for the password of my ssh keys. And as everyone can guess, my ssh key is protected by a password in the style above. This is no problem because pasting such passwords into Putty or other GUI applications works great.
So I wonder: is there a way how I can do safe pasting into windows shells?
I commend you on your passwords!
There's two major possibilities:
Some characters need to be escaped
Shift to a longer password without the escape-requiring characters
Escape the characters!
Code page fun, i.e. some characters are being transformed
Figure out the mapping and duplicate your KeePass entry with one that will map to the correct values for that login type
Shift to a longer password without the escape-requiring characters
Assuming your password (unlikely) is a 35 character password using all 256 possible 8 bit values, that's a maximum exhaustive keyspace of 256^35, roughly 2E84 or 2^280. You can achieve a slightly higher maximum exhaustive keyspace with a password of 43 charactres containing Upper, Lower, Number, and normal US keyboard symbols (94^43), or 48 characters containing Upper, Lower, and Number (62^48).
The Upper, Lower, Number password of length 48 shouldn't cause any problems with escaped characters, and is far less likely to cause problems with code page transforms.
Note that both of those are likely to be superior against the edge case of an attacker who knows which characters were actually used :).
Note also that even a 35 character password containing only Upper, Lower, and Number has a maximum exhaustive keyspace of 62^35, or 5.4E62, or 2^208; 208 bits is likely to substantially exceed the amount of security provided by your transport layer and/or their storage mechanism.
*All passwords in this math are assumed to be 100% cryptographically random!