I tried to decrypt pgp files somes are getting correctly decrypted but others are still having problem for decryption.
Command which i am using for decryption is :
pgp -z pass_phrase D:\PGP_FILES\file1.pgp -o D:\PGP_FILES\DecryptedFile
Its output :
Pretty Good Privacy(tm) Version 6.5.1
(c) 1999 Network Associates Inc.
Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc.
Export of this software may be restricted by the U.S. government.
File is encrypted. Secret key is required to read it.
Key for user ID: User <mail_id>
1024-bit RSA key, Key ID 0xABC, created date
Key can sign.
And stops after several minutes.
After the decryption is started output file is getting created and also its size is increasing till the end phase but after completion of decryption file is getting deleted automatically.
I am not getting reason behind the problem. So can anybody please help me come out of this situation? What is the exact problem?
Related
I have just gone to https://couchdb.apache.org/ to get the latest CouchDB binary (upgrading from 2.2).
However, the download link redirects me to an organisation called Neighbourhoodie - a CouchDB services & consultancy firm (which was unexpected, but understandable as I know the installations may be served from mirrors).
When I ran the installer I got a warning from Windows that the binary is from an 'Unknown Publisher'.
I can't find a contact point on the CouchDB site to ask a question like this.
The unexpected redirect coupled with the Unknown Publisher have made me nervous - how can I know that it's safe to proceed with the upgrade?
You can verify that the couchdb contributors that signs public releases believed this binary is correct for windows users by comparing the site, sha1 and md5 sums they gave in an issue. Neither a sha1 or md5 alone is secure, but I think it would be exceedingly hard to find an attack that simultaneously works for both.
Also, if you download the gpg signature, binary and the https://downloads.apache.org/couchdb/KEYS you can verify that this signer is the same signer using the same key recognized on the apache download site. Using their trust is similar to tofu, you trust the channel with https and it trusts this key, so now you trust the key on another channel.
On linux/mac this looks like:
(verify you obtain keys over ssl from apache, then:)
$ gpg --import KEYS.txt
...
gpg: key CDE711289384AE37: "**** (CODE SIGNING KEY) <****#apache.org>"
(download a sig and file from official downloads.apache.org site and verify + add your "tofu" trust in this key)
$ gpg --trusted-key CDE711289384AE37 --verify apache-couchdb-3.1.1.tar.gz.asc
(your gpg now trusts this key for new binaries)
$ gpg --verify apache-couchdb-3.1.0.msi.asc
(If the official KEYS file changes you would want to delete this trust and do the same process again:)
$ gpg --delete-key CDE711289384AE37
and windows gpg should look similar, maybe with / in place of --, etc.
I have an ETL that is Un-PGPing a file sent to us. This process works for two people on our team but fails for the rest on the unPGP step. We all use Kleopatra for our key encryption/decryption and have the same key's imported.
I have noticed that the keys on the systems that work are set to the trust level "This is my certificate" (sometimes called Ultimate trust). However the option to set to that level on the other systems are grayed out.
I have tried to change the level via a CMD prompt based on this article:
https://security.stackexchange.com/questions/129474/how-to-raise-a-key-to-ultimate-trust-on-another-machine
However I do not get the same prompts as described.
When debuging with CMD /K I see:
gpg: decryption failed: No secret key
UNPGP Failure Message
I found out how to change my trust,
gpg --edit-key [key-id]
trust
5
though this didn't end up solving my problems.
I discovered when I typed gpg --list-secret-keys I would get nothing in return despite having kleopatra tell me the keys were properly installed.
I found and staged the secret key's I needed then imported them using GPG.
gpg --allow-secret-key-import --import "filename.asc"
This fixed my issue!
I'm trying to compute digital signature RSASSA-PSS with sha256 for my IdentityIdentificationData (ASN1).
Directory file address 0x3D00
Aplication ID A000000061123A22738F4421
Private key folder 0x2F01
My ASN1 encoded hex data after sha256 encoded:
860c30a5f2b254ee92cbd3ec5c4282a940853aaef5f36d50ca20050637aaf4b0
I'm sending this command after SAM pin verified
MSE:SET
002241B606800191840110
SW1SW2:9000
Select File
00A40800043D002F0100
SW1SW2:9000
PSO: Compute Digital Signature
002A9E9A20860c30a5f2b254ee92cbd3ec5c4282a940853aaef5f36d50ca20050637aaf4b000
SW1SW2:6982
I'm a bit new on smart cards. How can i solve this problem. What is wrong or missing.
My SAM don't want to algorithm identifier for RSASSA-PSS.
6982 means: Security condition not satisfied
You should probably send the VERIFY PIN command directly before the PSO: Compute Digital Signature. Signature generation generally has very high requirements with regards to PIN, because the user has give consent for each and every signature. Hence the PIN may be invalidated by each command, especially if that command is an MSE:SET command. Selecting a DF by name may also influence the security environment.
So try the following order:
SELECT by Name (AID)
MSE:SET (for digital signature)
VERIFY PIN
PSO:COMPUTE DIGITAL SIGNATURE
The signature may also be depending on other security related objects such as an authentication key, for instance one used to setup secure messaging.
Can you check the access condition of RSA_Sign key ? If the access condition is NEVER then you wont be able to sign with this key. So in such case, SW 6982 make sense.
002241b606800191840181 mse:set is worked on me.
I configured msmtp with my gmail account.
I obviously want to avoid writing my password in plaintext format in the config file.
Luckily enough msmtp offer the option passwordeval which can be used to obtain the password from the output of an an executable.
The question is: how should I use it?
I found here the following suggestion:
passwordeval gpg -d /some/path/to/.msmtp.password.gpg
That doesn't make much sense to me: if someone is able to access my config file he will certainly manage to run such a command and obtain the password from gpg.
So I believe I'm left with the only option of obfuscating the password within the binary executable even if I read almost everywhere that this is bad!
My impossible-to-hack implementation is: if the sendmail process is running output the correct pass, otherwise give a fake pass.
Your suggestions?
Other (more secure) tricks different from storing the pass in the binary file?
From Sukima's comment:
The reason gpg -d works is because it requires the private key of the person the file is encrypted to. So just placing that encrypted file in the public it is still encrypted an only one person (the one with the secret key) can decrypt it. It is assumed that the secret key is locked up on the user's machine and not leaked. It also assumes that they have not setup any agents which cache the unlock password while a hacker has direct access to the same machine. All of which is highly unlikely in 99% of all attacks.
There is not a standard solution on how to save credentials with the constraint of
having to use the credentials in plain text later
and in an unattended way
on a system which is not completely controlled by you (if it is you just set appropriate rights on the files holding the secrets)
You have several solutions, none solves perfectly your problem:
encrypt your credentials in a symmetric way: you need to input the key to decrypt them
encrypt in an asymmetric way: you need to provide your private key, which must be stored somewhere (unattended approach) or keyed in
obfuscate: as you mention, this only protects from some population
get it from somewhere else - you need to identify a way or another your system
You need to take into account which risk is acceptable and go from there.
I need to be able to read card and company identification data from European digital tachograph company cards (smart cards). These are described within the document COMMISSION REGULATION (EC) No 1360/2002 but I have run into a problem. The data I need to be able to read is contained within the file EF Identification, which must be read with secure messaging and I therefore need to issue a Manage Secure Environment APDU command that requires a key identifier that identifies a key residing on the card.
I don't know where to find these key identifiers or the data that makes them up (described in an appendix of the document). I am waiting for feedback from our partners in Europe but thought I would take a chance an ask here in the hope that someone will have done this and be able to offer some advice.
The key identifier is made up of an equipment serial number, a date, a manufacturer code and a manufacturer specific type. This suggests a problem as I need to be able to access the data from any company card, regardless of manufacturer, issuer or holder. Not sure how I can get the data to compose the key.
I realise that this is pretty specialised information but have been stalled for over a week so am pretty desperate to find a solution so I can continue.
I believe that you first have to obtain a certificate from a country CA. You can then perform the following algorithm (simplified from Appendix 11, section 4):
Select and read the card certificate (EF_CERTIFICATE)
Issue a Manage Security Environment command to select the Root CA public key
Issue a Verify Certificate with the country CA certificate
Issue a Manage Security Environment command to select the country CA public key
Issue a Verify Certificate with your certificate
Issue a Manage Security Environment command to select your public key
Issue an Internal authenticate command. Verify response.
Issue a Get Challenge command
Issue an External authenticate command
Calculate the session key
Select File EF_IDENTIFICATION
Perform a Read Binary command using secure messaging (you need the session key to calculate the checksum and decrypt the result).
I don't know the standard, but I would assume that you read out EF Card_Certificate, recover the certificate content and extract the key identifier from that.
Assuming you have the root certificate (it is published here: http://dtc.jrc.it/erca_of_doc/EC_PK.zip), you will need to:
Read EF CA_Certificate
Follow the algorithm in Appendix 11, section 3.3.3
Extract the CA public key from the certificate content
Read EF Card_Certificate
Follow the algorithm in Appendix 11, section 3.3.3
The Key Identifier should now be byte 20-27 of the recovered certificate content.