I'd like to generate a public/private keypair from the command line which I can use for local testing with a NEAR Protocol account. How is this done?
There are multiple ways to generate keys for custody purposes. See custody docs for examples. From the docs:
Generally, any software that can produce valid ed25519 key pair can be used to generate the keys.
To generate a straightforward keypair (see format requirements), where both public and private key will be available in plaintext to you, you can use the near command line tools to output a keypair for an account (once you've installed them):
NEAR_ENV=mainnet near generate-key your-account-name
This creates a json keypair at ~/.near-credentials/mainnet/your-account-name.json
mainnet is the network this will be used with by default and also the folder within which the JSON file will live.
If you don't specify an account, one will be automatically generated, for example:
NEAR_ENV=mainnet near generate-key
Key pair with ed25519:6okNNRWxvWAyWMYxmgBQ2EWPyRm1FfppgXXWJELrFLXh public key for an account "5644304e7a48c7d425ffdaef027f1dfbd32eab129954b798eae501b610f3b680"
If you peek into the generated JSON file, which lives at ``~/.near-credentials/mainnet/5644304e7a48c7d425ffdaef027f1dfbd32eab129954b798eae501b610f3b680.json`, it looks like this:
{"account_id":"5644304e7a48c7d425ffdaef027f1dfbd32eab129954b798eae501b610f3b680","public_key":"ed25519:6okNNRWxvWAyWMYxmgBQ2EWPyRm1FfppgXXWJELrFLXh","private_key":"ed25519:5NDP1t4JijZHZzGnEkz3dancSWsLG3Gjss4WPXNPiHWNtdtvVJttW9uPqvxKMCwwPgtYvTxzQqDE7mSN72wXsMcK"}
The keypair generated each time is different, but the JSON files persist. And, yes, the keypair displayed above is purely for demonstration purposes and isn't linked to anything interesting :) (don't go sharing real keypairs on the internet, folks).
Troubeshooting -- you may need to double check your permissions to create or write to the ~/.near-credentials directory to make this work properly.
Related
I'm following instructions here and it says that I will find a bitcoin.conf file Windows: %APPDATA%\Bitcoin\ and
To use bitcoind and bitcoin-cli, you will need to add a RPC password to your bitcoin.conf file. Both programs will read from the same file if both run on the same system as the same user, so any long random password will work: rpcpassword=change_this_to_a_long_random_password
However When I navigate to %APPDATA%\Bitcoin\ I don't see a bitcoin.conf file.
So What do I do? Do I add a bitcoin.conf file? There is a bitcoin-conf.md file in doc in my bitcoin install directory so maybe somthing todo with that? I really don't know. Thanks for pointing me in the right direction.
That guide does not take into account the fact that you do not have to add any RPC user or password to your configuration file for the past some years.
Bitcoind will generate a cookie that allows the CLI (command line interface) to communicate with the Bitcoin daemon using RPC without the user having had to give it a single thought.
That is a developers' guide, so developers may have more complex requirements that are solved if they specify their own RPC authentication settings, such as running multiple wallets, or possibly exchange software that communicates with the wallet or multiple wallets.
bitcoin.conf being optional, it is not by default created, and is not needed for ordinary usage, only becoming necessary when the user or developer has particular, non-default settings to set.
The possible settings can be found by the help command bitcoind -help and lists a number of command line parameters (beginning with a dash or hyphen) that can be typed or pasted after bitcoind on the command line, but can be put in a text file named bitcoin.conf without the minus sign before the command. For example: -connect=IPAddress becomes simply connect=IPAddress in the conf file.
For creating suitable rpcauth (username and hashed password), and rpcuser and rpcpassword values, I've found some resources such as https://github.com/jlopp/bitcoin-core-rpc-auth-generator
Rather than serving JLopp's RPC auth generator locally you can simply copy from, or use a Python script found in the Bitcoin repository under the folder named "share", you will see a folder called rpcauth which contains the rpcauth.py script and a small explanatory file called README.md.
You have to create this file and put a single line rpcpassword=<your_password> in it.
bitcoin-conf.md contains documentation for this btcoin.conf and particularily states:
The configuration file is not automatically created; you can create it using your favorite text editor.
Recommended reading this doc. It may help you to facilitate running your node.
I haven't logged on to my EC2 recently in a few months. Last time I did, it seems like the RDP file that I downloaded had the password in it. That laptop died.
Today, it seems like AWS/EC2 has changed how things work. I'm able to download the RDP file, but it is prompting for a password. When I try to decrypt the password, it wants me to paste or browse to a file on my disk, which I don't have.
Is there a way to re-download my key info? On security then "Key Pairs", I see the key for this server. Can I download that to my disk, or open it somehow?
I see these steps, but they look overwhelming, i.e. I don't have time for that now; I have real work to do:
https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ResettingAdminPassword_EC2Config.html
I was able to create a new key pair, but not sure if I can associate it with the instance.
When I click "Get Password" this screen appears:
UPDATE 1: I did find my .pem file, so I was able to use that to logon.
Had I not found it, what would I do?
UPDATE 1: I did find my .pem file, so I was able to use that to logon. Had I not found it, what would I do?
Not much really! This is by design. AWS doesn't store your encryption key, and this prevents AWS personnel to access your instance. That's why you get such an ominous warning when pem file is generated: this is your one and only opportunity to see it - don't lose it.
That said, there are several however.
If you changed your Windows password in windows, or created a new AMI and launched a new instance from it - the pem file won't really help. You can probably create 2 administrator accounts; so if one forgets their password, you can reset it with another one.
Second - if your EBS is not encrypted, you can detach it, launch another instance, and attach EBS to new instance. You won't get your instance back, but you will get the data from that drive.
Finally, the "overwhelming" steps from the link that you posted. Follow good security posture, and you won't need them. But if you get sloppy, it may become your real work... better than polishing a resume...
When you receive a PGP message encrypted with your key, your PGP software can decrypt it because the message itself is encrypted with a one-time use random key and that random key is encrypted with your own key. Therefore, if you can get the random key ("session key" or "secret key"), then you can share it (and the original message) to prove to someone else what the original message said. This is what I need to do. I have been unable to find commands I can use in Windows or Linux to recover this random key. Does anyone know how to get it from the PGP message?
I'd also like to learn how to improve my search strategy because I believe the answer is already on the Internet and I just didn't search for the right keywords to find it.
echo '-----BEGIN PGP MESSAGE [...]' | gpg --show-session-key
It's okay if your PGP message spans multiple lines. You can paste it in and the presence of the first single quote causes the CLI to continue your input at the line breaks.
In Windows subsystem for Linux (aka WSL), you can use gpg to do this. One common problem with gpg is that it assumes it has a terminal connection (which is probably true) and that GPG_TTY is an environment variable that points to that connection (which might be false). The result of trying something in this case will produce Inappropriate ioctl for device and you can fix that with the following command: export GPG_TTY=$(tty)
You have to make sure the key you use to decrypt the message is in the keyring of the system you're using. I've been using Kleopatra in Windows and forgot that the keyring it uses is NOT shared with WSL, so I had to gpg --import [filename of my key] and enter my passphrase.
Once all that works, you'll get output that contains something like:
gpg: session key: '3:541FE563...
which you can use as described at https://security.stackexchange.com/questions/115231/how-to-decrypt-a-message-using-only-session-key to share the contents of the encrypted message without divulging your own private key. Thanks to Alex of Localmonero.com (aka Agoradesk.com) for helping me figure this out.
I wrote a helper script in Ruby to handle my file synchronization through some servers. It was used only in my intranet and authentication was made by SSH keys. But now I want to use it where I can't use SSH keys and I want to store the passwords in a config file.
I know, there are some encryption libraries like bcrypt or OpenSSL, but I have a problem with that:
I start my script and enter my passphrase and it is stored in a variable to decrypt my passwords.
My code is open source.
So everybody, who has access with my user to my computer (which would be the first barrier, which I'd like to extend) and looks into the memory (where my passphrase is stored) can decrypt my password file. How is that handled in applications which are relevant to security?
Edith says as a reply to DevDude (but here, because I want to keep my specifications in my question):
But then this configuration file would be plain text and not encrypted. And when I encrypt this file there are two more issues in my opinion:
The super_secret_pwd would be stored in a variable, so when I would search in the memory of the computer, I would find it, wouldnt I?
The master password for encryption would be in the memory as plain text, too.
So the big question is: Is it possible to read plain text variables from the memory? As I know it is possible in C and a big security issue.
What you are looking for is to use a YAML file with the password/API keys. and never check this file into your repo.
Then you can reference this file on your initializers, and maybe make the password a global variable or x, use configatron, etc.
This is basically how production applications work, they read their important settings from a YAML file stored on the server itself.
This is what I use:
#c = configatron
# Per environment settings
app_settings = YAML.load_file('config/secret_stuff.yml')
#c.password = app_settings['super_secret_pwd']
Do not use ENVIRONMENT variables because they have all sort of security issues. They are an antipattern.
I am using the cipher command to encrypt a file so that nobody can read that.
I tried this command : cipher /e /a exp\test.txt
I noticed the content of the file remained same. Only the file properties changed to encrypted. (Also the color of the filename changed to green. :P). I can still read, modify and delete the file.
Later I tried to decrypt: cipher /d /a exp\test.txt
The content as before same and in properties encrypted is unchecked.
I can read write and delete the file after encryption, what is the meaning of encryption then? How to use it properly? Am I missing something? Can anybody help me on this cipher command?
The cipher command on Windows allows you to control the encryption of files/directories provided by the Encrypting File System (EFS).
The important thing to note about EFS is that it is transparent encryption from the point of view of those granted access to the files. In other words, whilst the file data is encrypted on disk, providing you have keys to the file, you don't need to explicitly decrypt it in order to view the contents, it can just be read as any other file and the file system handles decrypting the data automatically. However, if you were to try and access the file as another user on the machine, or by reading data directly off the disk the file would be inaccessible.
You're not doing anything "wrong" here, it's just that cipher and EFS don't do what you expect them to.
The file is indeed encrypted at the file system level. That is, it's encrypted on disk, but NFTS will automatically decrypt on behalf of any application that is attempting to read that file running under your account.
Copy the encrypted file to a shared (NTFS) disk directory and validate it's still green in explorer. Then sign out and sign in with another account on this PC. I don't think you'll be able to read the file.