While reading RFC 4880 for OpenPGP, I read about version 3 and version 4 of OpenPGP keys. I do not understand what these versions mean other than specifying the packet format.
How can I find out a version of a key? I know for code we can use Bounce Castle's PGPPublicKey's getVersion(), but is there any command like keytool which I can use?
There is not a lot of difference between version 3 and 4 OpenPGP key packets, even the format is very similar. In version 4, the validity period was moved to special signatures, and fingerprint calculation changed. In detail, the changes (and formats) are described in OpenPGP, RFC 4880, 5.5.2. Public-Key Packet Formats. For signature packets, the differences are more significant.
To find the package version with readily-build tools, use gpg --list-packets or pgpdump, for example:
$ gpg --export a4ff2279 | gpg --list-packets
:public key packet:
version 4, algo 1, created 1356475387, expires 0
pkey[0]: [8192 bits]
pkey[1]: [17 bits]
keyid: 4E1F799AA4FF2279
[snip]
OpenPGP version 3 keys are deprecated for quite a while now, and rarely seen in usage.
Related
Vulnerability scanner is telling me:
"(..) Key exchanges should provide at least 224 bits for Elliptic Curve Diffie Hellman key exchanges."
One entry from vulnerability scan:
"Protocol: TLSv1.2 / Cipher: ECDHE-RSA-AES256-GCM-SHA384 / KeySize: 193"
Is there any way to restrict it to accept only keys bigger than 224 bits (registry or something) for Windows Server 2012 R2 and Windows Server 2016?
Registry check:
HKLM\SYSTEM\CurrentControlSet\Cryptography\Local\SSL\00010002\Functions
but I can't see on that list the cipher identified by vulnerability scanner.
Registry entry add:
HKLM\SYSTEM\CurrentControlSet\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\ECDHE
and create here two keys with decimal value
ServerMinKeyBitLength
ClientMinKeyBitLength
None of this worked.
Which is the standard size of the MAC generated with SHA-2?
it is safe if I trunk the message and then send it to destination ?
Thank you in advance for your consideration
First of all, do not use only the SHA2 hash funcion, but use HMAC (with SHA2).
Now for answering your question: In theory, you can use any size for your MAC, depending on your security requirements. However, the most recommended standard tag size is 128 bits (16 bytes).
We got this error when running this command :
[cacti ~]$ snmpwalk -v 3 -a MD5 -u super -x AES -X AAAAAA 10.X.X.X
2011-01-20 16:58:12 Error: passphrase chosen is below the length requirements of the USM (min=8).
2011-01-20 16:58:12 snmpwalk: (The supplied password length is too short.)
Error generating a key (Ku) from the supplied privacy pass phrase.
Do you have any idea how to decrease the USM's length parameter? We can't change the password that is under 8 characters..
You are fighting the IETF RFC if you insist using a short passphrase,
https://www.rfc-editor.org/rfc/rfc3414
If the Appendix A algorithm is used, SNMP implementations (and SNMP
configuration applications) must ensure that passwords are at least 8
characters in length.
This is a standard, so your only choice is to use a long enough passphrase.
For AES, the recommended passphrase length is 12,
http://www.ietf.org/rfc/rfc3826.txt
The following are recommended in regard to user passwords:
Password length SHOULD be at least 12 octets.
Password sharing SHOULD be prohibited so that passwords are not
shared among multiple SNMP users.
Implementations SHOULD support the use of randomly generated
passwords as a stronger form of security.
How do I make a Batch (or C/C++) script (running a gpg command hundreds of times) that is able to simulate the following keyboard input (and being intelligent enough to wait for input to be asked)?
8↵
S↵E↵Q↵
4096↵
0↵y↵
Jean Dupont↵
↵
born 1970-01-01 in Paris, France↵
O↵
correct horse battery staple↵
correct horse battery staple↵
I would like to generate myself a PGP keypair (for private communication), but I wish for the key's short id to be easy to remember, like FFFFFFFE for example.
The short id of a PGP key is the last 8 characters of its fingerprint. For your information, the fingerprint of a PGP key is a checksum (historically, SHA-1).
My wishes for the generated PGP key are the following:
Its short id (see above) must be easy to remember.
I want my key to be “unusual” so I have to use --expert mode.
By default, a generated key can both encrypt (E) and sign other people’s keys (C, “cert”), but I want mine to only sign other people’s keys.
Okay. So, I guess my solution for getting a “custom” key id is to generate lots of them (beware, I believe global entropy gets very diminished if you do that), and choose the one that I like most (like when your phone provider allows you to choose your future phone number in a list).
What I tried
By reading that page in the doc, I thought I could use gpg --batch --expert --gen-key gpg-keygen-settings.txt, with the following settings file:
Key-Type: RSA
Key-Length: 4096
Key-Usage: cert
Name-Real: Jean Dupont
Name-Comment: born 1970-01-01 in Paris, France
Expire-Date: 0
Passphrase: correct horse battery staple
%commit
%echo Done.
BUT it will not let me create a key whose usage is only to sign other people’s keys (cert). Indeed, the documentation says (for Key-Usage) that “Allowed values are ‘encrypt’, ‘sign’, and ‘auth’”. cert is the default, but using a blank Key-Usage field doesn’t work either.
What I believe I must do
I think the only way for me to generate all those keys with the settings I want, there is no solution but simulating key generation as if a real person was interactively running GPG’ shell.
Here is an excerpt of what must be done:
C:\> gpg --gen-key --expert
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
Your selection? 8
Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Sign Certify Encrypt
(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection?
[…]
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <heinrichh#duesseldorf.de>"
Real name: […]
[…]
So, uh.
Thank you very much.
Weird request, I know. Chuckles
Well, I didn’t find the solution I was looking for (something I could make run in background, not buggy, etc.)—and I am still open, for my personal culture, to better solutions and answers.
Anyway, here is the AutoHotkey script I came up with. Very dirty. I coded a bit, then gave up and used the AutoScriptWriter tool to record a macro, and adapted the code to suit my needs (haha). The most annoying thing was to learn how to interact with GPG-Agent (pinentry).
Loop 100
{
Run, cmd.exe /k "gpg --expert --gen-key"
WinWait, C:\Windows\SYSTEM32\cmd.exe - gpg --expert --gen-key,
IfWinNotActive, C:\Windows\SYSTEM32\cmd.exe - gpg --expert --gen-key, , WinActivate, C:\Windows\SYSTEM32\cmd.exe - gpg --expert --gen-key,
WinWaitActive, C:\Windows\SYSTEM32\cmd.exe - gpg --expert --gen-key,
Sleep 1500
Send +8{Enter}
Send S{Enter}C{Enter}Q{Enter}
Send +4+0+9+6{Enter}
Send +0{Enter}o{Enter}
Send Jean Dupont{Enter}
Send {Enter}
Send born {Shift Down}1970{Shift Up}6{Shift Down}01{Shift Up}6{Shift Down}01{Shift Up} in Paris, France{Enter}O{Enter}
; The "6" keypress above is to make a - on French AZERTY keyboards.
WinWait, pinentry,
IfWinNotActive, pinentry, , WinActivate, pinentry,
WinWaitActive, pinentry,
Send, correct horse battery staple{ENTER}
Sleep 1500
Send, correct horse battery staple{ENTER}
Sleep 10000
;Send exit{Enter}
}
This little script allowed me to get a bucketload of keys, one of which having a short id I like.
I'm working with an older version of OpenSSL, and I'm running into some behavior that has stumped me for days when trying to work with cross-platform code.
I have code that calls OpenSSL to sign something. My code is modeled after the code in ASN1_sign, which is found in a_sign.c in OpenSSL, which exhibits the same issues when I use it. Here is the relevant line of code (which is found and used exactly the same way in a_sign.c):
EVP_SignUpdate(&ctx,(unsigned char *)buf_in,inl);
ctx is a structure that OpenSSL uses, not relevant to this discussion
buf_in is a char* of the data that is to be signed
inl is the length of buf_in
EVP_SignUpdate can be called repeatedly in order to read in data to be signed before EVP_SignFinal is called to sign it.
Everything works fine when this code is used on Ubuntu and Windows 7, both of them produce the exact same signatures given the same inputs.
On OS X, if the size of inl is less than 64 (that is there are 64 bytes or less in buf_in), then it too produces the same signatures as Ubuntu and Windows. However, if the size of inl becomes greater than 64, it produces its own internally consistent signatures that differ from the other platforms. By internally consistent, I mean that the Mac will read the signatures and verify them as proper, while it will reject the signatures from Ubuntu and Windows, and vice versa.
I managed to fix this issue, and cause the same signatures to be created by changing that line above to the following, where it reads the buffer one byte at a time:
int input_it;
for(input_it = (int)buf_in; input_it < inl + (int)buf_in; intput_it++){
EVP_SIGNUpdate(&ctx, (unsigned char*) input_it, 1);
}
This causes OS X to reject its own signatures of data > 64 bytes as invalid, and I tracked down a similar line elsewhere for verifying signatures that needed to be broken up in an identical manner.
This fixes the signature creation and verification, but something is still going wrong, as I'm encountering other problems, and I really don't want to go traipsing (and modifying!) much deeper into OpenSSL.
Surely I'm doing something wrong, as I'm seeing the exact same issues when I use stock ASN1_sign. Is this an issue with the way that I compiled OpenSSL? For the life of me I can't figure it out. Can anyone educate me on what bone-headed mistake I must be making?
This is likely a bug in the MacOS implementation. I recommend you file a bug by sending the above text to the developers as described at http://www.openssl.org/support/faq.html#BUILD17
There are known issues with OpenSSL on the mac (you have to jump through a few hoops to ensure it links with the correct library instead of the system library). Did you compile it yourself? The PROBLEMS file in the distribution explains the details of the issue and suggests a few workarounds. (Or if you are running with shared libraries, double check that your DYLD_LIBRARY_PATH is correctly set). No guarantee, but this looks a likely place to start...
The most common issue porting Windows and Linux code around is default values of memory. I think Windows sets it to 0xDEADBEEF and Linux set's it to 0s.