Thanks for your reply. I think I have it down now. What I am going to do
is:
1. Read the key in to pemBlk
2. See if it's got a passcode
3. If it does decrypt
```
if x509.IsEncryptedPEMBlock(pemBlk) {
keyPEMBlock, err = x509.DecryptPEMBlock(pemBlk, []byte(passphrase))
```
As to having to have a human enter the passcode on each restart. I have a
json configuration file that contains directives for where the keypair is
an the passphrase. Read the passcode, try to decrypt it. If the decrypt
fails -- its probably in clear text so encrypt it and write it back to the
config file. This way all the person has to do is put the passphrase in
clear text, restart application, password is now encrypted in the config
file. When the password changes because the key changed (once a year),
change the config (plaintext) and restart -- passphrase is then encrypted.
On Sunday, October 18, 2020 at 9:01:23 PM UTC-4 pat2...@gmail.com wrote:
> On Sunday, October 18, 2020 at 4:39:46 PM UTC-4 Rich wrote:
>
>> I have no problem writing this myself and I already have ideas on what I
>> am going to do, but before I do that I thought I'd ask and see if anyone
>> knew of a package, or some easier way that did this already. I've spent
>> hours in the past writing code only to find later someone has written a
>> great package that does what I need and more. Never hurts to ask right ;
>>
>
> The great packages have been written. But the real solution is to use a
> service either in software like AWS Secrets Manager or in a hardware box
> like the banking networks like. If your company has had this policy a long
> time, use whatever other systems have used.
>
> Writing crypto software that seems to work is not hard. For this case,
> have the operator enter a passphrase, run it thru a HMAC, and then use AES
> 256 to encipher/decipher the CERT. Store the binary in some standard
> format, try to avoid ANS.1 if you can possibly do it.
>
> Writing crypto software that really works, is secure, etc. is very hard.
> No offense, but you are unlikely to do it.
>
> I don't understand how this is supposed to work. Do you ask the system's
> operator to type in the passphrase every time the service is restarted?
> Most modern systems don't have a human operator to do such typing. And how
> do you ensure that there is no keyboard logger on the operator's terminal?
> Or are you keeping the passphrase in someplace like an environment variable
> or a secret file?
>
> The software and the crypto are only a tiny part of the issue. Either do
> whatever made them happy in the past, or find out what is really driving
> this "requirement".
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/a6279a0d-63e6-4c2d-8047-cd7c7905956dn%40googlegroups.com.
