Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
When some data is encrypted with PGP, no password is provided. What is the password used in the symmetric algorithms portion of PGP?
this is the output of a small string encrypted with AES 256.
-----BEGIN PGP MESSAGE-----
Version: BCPG v1.39
hI4D+UDEMBpnd50QAf9bWG97E9FfnSKB/WpVcBtLJqk5f/Ih9YZTUDULDZpSE0TP
ObJnCs91okOv6/BtDRDZ84ChF5pOZezb5+aL3TW5AfwK3gJ7nPTlmZOm5Kf7qOfB
n307xpn0qRw395y1mfOm10TsMpaCkbSvwjhqPi8hRMM17y29OsqGLstZdeAaNTGt
0mwB7EiZti4jOUF3/SCNnn2vA9hVc6o6c0l0h5vQOF0L+eL1Pmhg8RcFT4kHRnI/
A+Ad4hsbOxD1vvzZHx2iETkt1JmNTHmOOY5Cw/n+sFlU9JzZpzAtqwUjjnyN8NjQ
6NbpwL6gebTJCVTNW2c=
=kI32
-----END PGP MESSAGE-----
Old: Public-Key Encrypted Session Key Packet(tag 1)(142 bytes)
New version(3)
Key ID - 0xF940C4301A67779D
Pub alg - ElGamal Encrypt-Only(pub 16)
ElGamal g^k mod p(511 bits) - 5b 58 6f 7b 13 d1 5f 9d 22 81 fd 6a 55 70 1b 4b 26 a9 39 7f f2 21 f5 86 53 50 35 0b 0d 9a 52 13 44 cf 39 b2 67 0a cf 75 a2 43 af eb f0 6d 0d 10 d9 f3 80 a1 17 9a 4e 65 ec db e7 e6 8b dd 35 b9
ElGamal m * y^k mod p(508 bits) - 0a de 02 7b 9c f4 e5 99 93 a6 e4 a7 fb a8 e7 c1 9f 7d 3b c6 99 f4 a9 1c 37 f7 9c b5 99 f3 a6 d7 44 ec 32 96 82 91 b4 af c2 38 6a 3e 2f 21 44 c3 35 ef 2d bd 3a ca 86 2e cb 59 75 e0 1a 35 31 ad
-> m = sym alg(1 byte) + checksum(2 bytes) + PKCS-1 block type 02
New: Symmetrically Encrypted and MDC Packet(tag 18)(108 bytes)
Ver 1
Encrypted data [sym alg is specified in pub-key encrypted session key]
(plain text + MDC SHA1(20 bytes))
I know that the AES 256 value 9 is hidden in the first packet (tag 1), but where is the key? Since the public key is used to encrypt, there was no key hidden in the public key with which to encrypt. Also, I think RFC 4880 never actually specifies where to get a key.
Am i missing some important point about public key cryptography?
You don't need a key because anyone may use the public key. The public key is used for encrypting (in this case a random AES key, which is used to encrypt the rest of the data). Only during decryption will you need the private key to retrieve the encrypted AES key and - of course - the data. This is of course the public/private key pair of the receiving party(s).
The randomly-generated session key is stored in the first packet:
... Public-Key Encrypted Session Key Packet ...
Raw data is never encrypted directly with public key algorithms; instead, a randomly-generated session key is used. If you encrypt to multiple recipients, the same session key will be encrypted to each recipient individually.
I just realized that i misinterpreted session key in the instructions as the packet, rather than the secret key
Related
Currently, I am attempting to generating a hash of a user password for PDF, given the encrypted PDF file and the plain password. I follow the instruction of this article. However, the hash I've computed is different from the hash stored in the PDF file.
The hashed user password (/U entry) is simply the 32-byte padding
string above, encrypted with RC4, using the 5-byte file key. Compliant
PDF viewers will check the password given by the user (by attempting
to decrypt the /U entry using the file key, and comparing it against
the padding string) and allow or refuse certain operations based on
the permission settings.
First, I padded my password "123456" using a hardcoded 32-byte string, which gives me
31 32 33 34 35 36 28 BF 4E 5E 4E 75 8A 41 64 00
4E 56 FF FA 01 08 2E 2E 00 B6 D0 68 3E 80 2F 0C
I tried to compute the hash with RC4 using the 5-byte file key as the key. According to the article:
The encryption key is generated as follows:
1. Pad the user password out to 32 bytes, using a hardcoded
32-byte string:
28 BF 4E 5E 4E 75 8A 41 64 00 4E 56 FF FA 01 08
2E 2E 00 B6 D0 68 3E 80 2F 0C A9 FE 64 53 69 7A
If the user password is null, just use the entire padding
string. (I.e., concatenate the user password and the padding
string and take the first 32 bytes.)
2. Append the hashed owner password (the /O entry above).
3. Append the permissions (the /P entry), treated as a four-byte
integer, LSB first.
4. Append the file identifier (the /ID entry from the trailer
dictionary). This is an arbitrary string of bytes; Adobe
recommends that it be generated by MD5 hashing various pieces
of information about the document.
5. MD5 hash this string; the first 5 bytes of output are the
encryption key. (This is a 40-bit key, presumably to meet US
export regulations.)
I appended the hashed owner key to the padded password, which gives me
31 32 33 34 35 36 28 BF 4E 5E 4E 75 8A 41 64 00
4E 56 FF FA 01 08 2E 2E 00 B6 D0 68 3E 80 2F 0C
C4 31 FA B9 CC 5E F7 B5 9C 24 4B 61 B7 45 F7 1A
C5 BA 42 7B 1B 91 02 DA 46 8E 77 12 7F 1E 69 D6
Then, I appended the /P entry (-4), treated as a four-byte integer, encoded with little endian, which gives me
31 32 33 34 35 36 28 BF 4E 5E 4E 75 8A 41 64 00
4E 56 FF FA 01 08 2E 2E 00 B6 D0 68 3E 80 2F 0C
C4 31 FA B9 CC 5E F7 B5 9C 24 4B 61 B7 45 F7 1A
C5 BA 42 7B 1B 91 02 DA 46 8E 77 12 7F 1E 69 D6
FC FF FF FF
Last, I appended the file identifier to it. The trailer of my PDF is:
trailer
<<
/Size 13
/Root 2 0 R
/Encrypt 1 0 R
/Info 4 0 R
/ID [<B5185D941CC0EA39ACA809F661EF36D4> <393BE725532F9158DC9E6E8EA97CFBF0>]
>>
and the result is
31 32 33 34 35 36 28 BF 4E 5E 4E 75 8A 41 64 00
4E 56 FF FA 01 08 2E 2E 00 B6 D0 68 3E 80 2F 0C
C4 31 FA B9 CC 5E F7 B5 9C 24 4B 61 B7 45 F7 1A
C5 BA 42 7B 1B 91 02 DA 46 8E 77 12 7F 1E 69 D6
FC FF FF FF B5 18 5D 94 1C C0 EA 39 AC A8 09 F6
61 EF 36 D4 39 3B E7 25 53 2F 91 58 DC 9E 6E 8E
A9 7C FB F0
MD5 hashing this block of data returns 942c5e7b2020ce57ce4408f531a65019. I RC4-ed the padded password with cryptii using the first 5 bytes of the MD5 hash as the key. However, it returns
90 e2 b5 21 2a 7d 53 05 70 d9 5d 26 95 c7 c2 05
6e 2a 28 40 63 e7 4a d4 e9 05 86 71 43 d1 39 d6
while the hash in PDF is
58 81 CA 74 65 DC 2E A7 5D D2 39 D4 43 9C 0D DE
28 BF 4E 5E 4E 75 8A 41 64 00 4E 56 FF FA 01 08
Which step am I doing wrong? I suspect that the problem happens because
I am appending the File Idenifier in a wrong format
I am using the wrong drop bytes with RC4.
The hash function is not for PDF 1.6
I make some mistake during those process
Or maybe the article is actually wrong
Files: Original PDF dummy.pdf, dummy-protected.pdf (Password: 123456)
Please help
There are two issues in your calculation:
The article to use refers to PDF encryption algorithms available for PDF-1.3 but your document is encrypted using an algorithm introduced with PDF-1.5.
You make an error when appending the file identifier - actually only the first entry of the ID array shall be appended, not both (which is not really clear from the article you use).
In a comment you asked accordingly
where can I find the password hashing detail for >V1.3 PDF?
I would propose using the PDF specification, ISO 32000.
As ISO specifications go, they are not free, but Adobe used to provide a version of ISO 32000-1 with merely the ISO header removed on their web site. Some days ago it has been removed (By design? By error? I don't know yet.) but you still find copies of it googl'ing for "PDF32000".
The relevant section in ISO 32000-1 is 7.6 Encryption and in particular 7.6.3 Standard Security Handler.
Following that information you should be able to correctly calculate the value in question.
(Alternatively you can also use old Adobe PDF references, the editions for PDF 1.5, 1.6, and 1.7 should also give you the information required for decrypting your document. But these references have been characterized as not normative in nature by prominent Adobe employees, so I would go for the ISO norm.)
Beware, though: After ISO 32000-1 had been published, Adobe introduced an AES-256 encryption scheme as an extension which obviously is not included in ISO 32000-1. You can find a specification in "Adobe Supplement to ISO 32000, base version 1.7, extension level 3".
Furthermore, with ISO 32000-2 that Adobe AES-256 encryption scheme and all older schemes became deprecated, the only encryption scheme to use with PDF-2.0 is a new AES-256 encryption scheme described in ISO 32000-2 which is based on the Adobe scheme but introduces some extra hashing iterations.
I have a byte[], which holds a complete PGP Signed Message, consisting of: One-Pass Signature, Literal Data and Signature. Let's assume this is the representation of this message:
�
_�P��8��y_�(b__CONSOLE_C�}Lorem ipsum dolor sit amet�^_�}
_�P��8��y_�_�ց�� v_0:��^_�V=�ʙ
̡W_"_3�=_�8�8�/��g[;_"e_��_�"6�_�pJ���;��
I want to read that message into corresponding objects, i.e. PGPOnePassSignature, byte[] and PGPSignature. In order to do so, I follow the usual mantra:
PGPOnePassSignatureList onePassSignatureList = (PGPOnePassSignatureList) pgpObjectFactory.nextObject();
onePassSignatureList.get(0);
This should give me One-Pass Signature. I then carry on reading the remainder of the message also using pgpObjectFactory of class JcaPGPObjectFactory. The problem is what I get is the original PGP Signed Message with incomplete One-Pass Signature:
�
_�P��8��y_Lorem ipsum dolor sit amet�^_�}
_�P��8��y_�_�ց�� v_0:��^_�V=�ʙ
̡W_"_3�=_�8�8�/��g[;_"e_��_�"6�_�pJ���;��
It's clearly the above code snippet which is not capable of recovering One-Pass Signature in full.
You can easily see the part inlcuding _CONSOLE is missing. Byte array size is 137 recovered message vs 153 original message.
Is it possible to recover original message in full?
Library version:
org.bouncycastle:bcpg-jdk15on:1.66
It's impossible to analyze your message, because binary data handled as text is garbled and corrupted, and you don't show your code. But you are correct that a PGP signed message can consist of onepass-signature packet, literal data packet, and signature packet. Note that literal data is not just data, it contains some metadata also. In particular, the _CONSOLE you seem to focus on is a special value for the filename field, and not part of the actual data.
BouncyCastle PGPObjectFactory returns this as PGPOnePassSignatureList PGPLiteralData (not byte[]) PGPSignatureList. Using this message signed on my test system:
$ od -tx1 zgpgs0
0000000 90 0d 03 00 08 11 81 e0 c1 00 62 85 ee 50 01 ac
0000020 10 62 02 79 31 5f 44 29 59 66 6f 6f 62 61 72 0d
0000040 0a 88 5e 04 00 11 08 00 06 05 02 5f 44 29 5a 00
0000060 0a 09 10 81 e0 c1 00 62 85 ee 50 5b 9d 01 00 da
0000100 6c d0 53 7b fb 21 1c df 5a 5d b1 05 d9 48 b6 37
0000120 79 56 16 73 dc bf a8 4d 37 cd a9 af bb f0 43 01
0000140 00 91 14 de 16 c5 41 b6 3d c4 f0 52 a9 1e d9 82
0000160 65 3e 65 a4 a5 03 c2 55 f1 46 27 c3 aa c4 12 5c
0000200 73
0000201
$ gpg --list-packets zgpgs0
:onepass_sig packet: keyid 81E0C1006285EE50
version 3, sigclass 0x00, digest 8, pubkey 17, last=1
:literal data packet:
mode b (62), created 1598302553, name="y1",
raw data: 8 bytes
:signature packet: algo 17, keyid 81E0C1006285EE50
version 4, created 1598302554, md5len 0, sigclass 0x00
digest algo 8, begin of digest 5b 9d
hashed subpkt 2 len 4 (sig created 2020-08-24)
subpkt 16 len 8 (issuer key ID 81E0C1006285EE50)
data: [256 bits]
data: [256 bits]
$
this code:
JcaPGPObjectFactory pgpFact = new JcaPGPObjectFactory(new FileInputStream(args[0]));
Object t; while( (t = pgpFact.nextObject()) != null ){
System.out.println (t.getClass().getName());
if( t instanceof PGPLiteralData ){
PGPLiteralData lit = (PGPLiteralData)t;
System.out.println("format="+ lit.getFormat());
System.out.println("filename="+lit.getFileName());
System.out.println("modtime="+lit.getModificationTime());
InputStream s = lit.getInputStream();
byte[] buf = new byte[1000]; int len = s.read(buf);
System.out.println("data:"+new String(buf,0,len,StandardCharsets.ISO_8859_1));
}
}
gives this output:
org.bouncycastle.openpgp.PGPOnePassSignatureList
org.bouncycastle.openpgp.PGPLiteralData
format=98
filename=y1
modtime=Mon Aug 24 20:55:53 UTC 2020
data:foobar
org.bouncycastle.openpgp.PGPSignatureList
I incorrectly assumed that the bit I'm missing is part of the One-Pass Signature. This was indeed part of Literal Data metadata, which I was able to read and re-construct the literal data as needed using this code snippet:
private void parseMessage(JcaPGPObjectFactory pgpObjectFactory) throws Exception {
PGPLiteralData pgpLiteralData = (PGPLiteralData) pgpObjectFactory.nextObject();
String filename = pgpLiteralData.getFileName();
Date modificationTime = pgpLiteralData.getModificationTime();
char pgpLiteralDataType = (char) pgpLiteralData.getFormat();
InputStream pgpLiteralDataInputStream = pgpLiteralData.getInputStream();
byte[] message = Streams.readAll(pgpLiteralDataInputStream);
pgpLiteralDataInputStream.close();
ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
BCPGOutputStream onePassSignatureOutputStream = new BCPGOutputStream(byteArrayOutputStream);
PGPLiteralDataGenerator pgpLiteralDataGenerator = new PGPLiteralDataGenerator();
OutputStream outputStream = pgpLiteralDataGenerator.open(
onePassSignatureOutputStream,
pgpLiteralDataType,
filename,
message.length,
modificationTime
);
outputStream.write(message);
pgpLiteralDataGenerator.close();
outputStream.close();
onePassSignatureOutputStream.close();
byteArrayOutputStream.close();
literalData = byteArrayOutputStream.toByteArray();
}
I have two queue manager servers running on two boxes. QM1 has a sender channel defined , and QM2 has a receiver channel with the same name.
I have created self signed certificate for each QM , extracted and added the public part of each certificate to the other QM's key db. Altered each channel to use CipherSpec TRIPLE_DES_SHA_US.
This setup works perfectly fine, if QM names don't contain any special character. If name of the sender QM is A_QM and the other one is B_QM , the sender channel never comes up and is in RETRYING state.
while creating self-signed certificate I am using label ibmwebspheremqa_qm
in case of A_QM and ibmwebspheremqqm1 when the queue manager is QM1. Similarly when adding the public part of the certificate I am preserving the other QM's label. This is the only difference in the whole setup.
Is there any restriction in defining QM names if I want to configure SSL or TLS ?
I had no trouble creating a pair of QMgrs and channels as described and getting them to run:
[mqm#rhel6base scripts]$ runmqsc A_QM
5724-H72 (C) Copyright IBM Corp. 1994, 2014.
Starting MQSC for queue manager A_QM.
dis chs(*) all
1 : dis chs(*) all
AMQ8417: Display Channel Status details.
CHANNEL(A_QM.B_QM) CHLTYPE(SDR)
BATCHES(0) BATCHSZ(50)
BUFSRCVD(1) BUFSSENT(1)
BYTSRCVD(268) BYTSSENT(268)
CHSTADA(2015-04-01) CHSTATI(10.57.43)
COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
COMPRATE(0,0) COMPTIME(0,0)
CONNAME(127.0.0.1(3115)) CURLUWID(0C031C5501020010)
CURMSGS(0) CURRENT
CURSEQNO(0) EXITTIME(0,0)
HBINT(300) INDOUBT(NO)
JOBNAME(0000130700000001) LOCLADDR(127.0.0.1(53145))
LONGRTS(999999999) LSTLUWID(0000000000000000)
LSTMSGDA( ) LSTMSGTI( )
LSTSEQNO(0) MCASTAT(RUNNING)
MONCHL(OFF) MSGS(0)
NETTIME(0,0) NPMSPEED(FAST)
RQMNAME(B_QM) SHORTRTS(10)
SSLCERTI(CN=rhel6base.ioptconsulting.com)
SSLKEYDA( ) SSLKEYTI( )
SSLPEER(SERIALNUMBER=55:1C:06:B2,CN=rhel6base.ioptconsulting.com)
SSLRKEYS(0) STATUS(RUNNING)
STOPREQ(NO) SUBSTATE(MQGET)
XBATCHSZ(0,0) XMITQ(B_QM)
XQTIME(0,0) RVERSION(08000001)
RPRODUCT(MQMM)
[mqm#rhel6base ssl]$ runmqakm -cert -list -db key.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
! ibmwebspheremqb_qm
*- ibmwebspheremqa_qm
[mqm#rhel6base ssl]$ runmqakm -cert -list -db ../../B_QM/ssl/key.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
! ibmwebspheremq_a_qm
*- ibmwebspheremqb_qm
[mqm#rhel6base ssl]$
REFRESH SECURITY TYPE(SSL)
The most likely cause for the behavior you are seeing is not issuing refresh security or restarting the QMgrs after updating their keystores. For example:
echo "REFRESH SECURITY TYPE(SSL)" | runmqsc A_QM
echo "REFRESH SECURITY TYPE(SSL)" | runmqsc B_QM
or
endmqm -i A_QM; strmqm A_QM
endmqm -i B_QM; strmqm B_QM
One aspect of security for the keystore is that there is only ever one version of it in memory at a time. If it were possible for one channel to have one version and another channel to have another version, it would become impossible to determine which was the "right" one in order to detect tampering. So when the KDB is updated, the refresh security command causes the QMgr to stop all running TLS channels, dump the KDB from memory, and reload the KDB when one of the channels starts.
(MQ doesn't use SSL, by the way, never has. It uses TLS with SSL ciphers and now that SSL itself is broken, best to get used to saying TLS because that will help to remember to use TLS ciphers exclusively going forward.)
So after updating the KDB if you did not run the refresh, it is likely that the refresh was not done and the QMgr doesn't yet know about the newly added certificate for the remote QMgr.
When SSLCAUTH(OPTIONAL) is not optional
Another common problem with TLS is a misunderstanding of SSLCAUTH(OPTIONAL). Many people believe that this always results in one-way authentication so they set SSLCAUTH(OPTIONAL) and then exchange certs in only one direction. For example, QM1 has TLS channels to QM2 so obviously has its own personal certificate. Then we try to connect A_QM to it. We import A_QM's personal cert to QM1's KDB, refresh security everywhere, DEF CHL(A_QM.QM1) ... SSLCAUTH(OPTIONAL) on both sides and try to start the channel.
The misunderstanding is that if the thing initiating the channel has a personal cert it will send it in all cases. To test with SSLCAUTH(OPTIONAL) requires removing any personal cert from the keystore on the side initiating the connection. Often people do not realize this and spend many hours (in some cases weeks) struggling to understand why this fails.
For your purposes always exchange the personal certs in both directions.
Incomplete cert exchange
The other common problem working with self-signed certs is when a cert is generated multiple times with the same label and/or CN value and there's a mismatch between the personal cert on one end versus the public portion on the other. This is easily checked by viewing the cert details and checking that the fingerprint and other details match like so:
[mqm#rhel6base ssl]$ runmqakm -cert -details -label ibmwebspheremqb_qm -db key.kdb -stashed
Label : ibmwebspheremqb_qm
Key Size : 1024
Version : X509 V3
Serial : 551c06b2
Issuer : CN=rhel6base.ioptconsulting.com
Subject : CN=rhel6base.ioptconsulting.com
Not Before : April 1, 2015 10:54:42 AM EDT
Not After : March 31, 2016 10:54:42 AM EDT
Public Key
30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01
05 00 03 81 8D 00 30 81 89 02 81 81 00 DF 0F 90
8C C2 CA D1 ED 16 E2 A8 DA E3 26 63 45 4B B2 29
37 04 65 A1 D3 30 23 2A 67 AB 61 06 75 E1 8B 87
D2 9A CD 38 4C 63 D6 CC AD 25 55 B3 8B BE 34 4E
32 CB EB FE E2 5D E0 49 2F 57 AC EC 5E 79 A2 52
F6 21 5A 5F 95 AB C4 70 C8 00 68 0B 22 32 8C 1F
4C DB 0C D9 85 B8 06 5A 7C DA 3A 3A BE 12 C8 C1
C0 92 5E FE 09 46 F7 E1 1F 3D 4A AA 63 F0 80 09
3D FE E7 A4 49 5D 86 09 4C B5 0E 1E 97 02 03 01
00 01
Public Key Type : RSA (1.2.840.113549.1.1.1)
Fingerprint : SHA1 :
55 FC 2C 7C 00 8E A7 27 78 0D 99 AD FF 84 58 57
BF 16 1C 62
Fingerprint : MD5 :
90 66 AD 5D 71 AF 75 E8 9A 4A A3 5A DB 15 CD 21
Fingerprint : SHA256 :
7E 43 75 25 31 ED E7 76 FA 40 87 37 F3 B2 9E 6F
2D 55 2D 3C CB 52 60 9C 85 B2 53 F3 1C C0 D2 3C
Extensions
AuthorityKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
authorityIdentifier:
authorityCertSerialNumber:
SubjectKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
Signature Algorithm : SHA1WithRSASignature (1.2.840.113549.1.1.5)
Value
46 D4 8A D9 62 04 CF C4 0E 23 DB 4C F9 AD 25 9B
89 3B FD B9 4F 52 4C DE 36 96 15 92 0E 7B 03 05
E8 85 12 AD E7 40 DB E9 4D 77 8F B7 4B CC 43 1B
AD 6D 13 B1 2F 26 12 C8 1C 17 FE 51 A7 B7 7B EE
80 CA 82 37 98 E1 B4 17 3A B4 CC 20 E7 4E 53 42
C6 E1 C3 1C 54 BD DC 9A 14 86 9A 25 66 AC 11 2C
78 A0 B5 DC 22 FE 52 62 59 27 02 DA 82 07 64 42
38 99 8A A7 52 53 20 C3 B2 FF 8F 6D A6 A3 8F 72
Trust Status : Enabled
[mqm#rhel6base ssl]$ runmqakm -cert -details -label ibmwebspheremqb_qm -db ../../B_QM/ssl/key.kdb -stashed
Label : ibmwebspheremqb_qm
Key Size : 1024
Version : X509 V3
Serial : 551c06b2
Issuer : CN=rhel6base.ioptconsulting.com
Subject : CN=rhel6base.ioptconsulting.com
Not Before : April 1, 2015 10:54:42 AM EDT
Not After : March 31, 2016 10:54:42 AM EDT
Public Key
30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01
05 00 03 81 8D 00 30 81 89 02 81 81 00 DF 0F 90
8C C2 CA D1 ED 16 E2 A8 DA E3 26 63 45 4B B2 29
37 04 65 A1 D3 30 23 2A 67 AB 61 06 75 E1 8B 87
D2 9A CD 38 4C 63 D6 CC AD 25 55 B3 8B BE 34 4E
32 CB EB FE E2 5D E0 49 2F 57 AC EC 5E 79 A2 52
F6 21 5A 5F 95 AB C4 70 C8 00 68 0B 22 32 8C 1F
4C DB 0C D9 85 B8 06 5A 7C DA 3A 3A BE 12 C8 C1
C0 92 5E FE 09 46 F7 E1 1F 3D 4A AA 63 F0 80 09
3D FE E7 A4 49 5D 86 09 4C B5 0E 1E 97 02 03 01
00 01
Public Key Type : RSA (1.2.840.113549.1.1.1)
Fingerprint : SHA1 :
55 FC 2C 7C 00 8E A7 27 78 0D 99 AD FF 84 58 57
BF 16 1C 62
Fingerprint : MD5 :
90 66 AD 5D 71 AF 75 E8 9A 4A A3 5A DB 15 CD 21
Fingerprint : SHA256 :
7E 43 75 25 31 ED E7 76 FA 40 87 37 F3 B2 9E 6F
2D 55 2D 3C CB 52 60 9C 85 B2 53 F3 1C C0 D2 3C
Extensions
AuthorityKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
authorityIdentifier:
authorityCertSerialNumber:
SubjectKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
Signature Algorithm : SHA1WithRSASignature (1.2.840.113549.1.1.5)
Value
46 D4 8A D9 62 04 CF C4 0E 23 DB 4C F9 AD 25 9B
89 3B FD B9 4F 52 4C DE 36 96 15 92 0E 7B 03 05
E8 85 12 AD E7 40 DB E9 4D 77 8F B7 4B CC 43 1B
AD 6D 13 B1 2F 26 12 C8 1C 17 FE 51 A7 B7 7B EE
80 CA 82 37 98 E1 B4 17 3A B4 CC 20 E7 4E 53 42
C6 E1 C3 1C 54 BD DC 9A 14 86 9A 25 66 AC 11 2C
78 A0 B5 DC 22 FE 52 62 59 27 02 DA 82 07 64 42
38 99 8A A7 52 53 20 C3 B2 FF 8F 6D A6 A3 8F 72
Trust Status : Enabled
Debugging
Check the error logs. In particular, it is good security design to give an attacker as little information as possible to always check the logs of the QMgr that is receiving the connection first. If it has detected the error it will have detailed logs and the sending side will have sparse logs like "the remote QMgr disconnected" which doesn't reveal much to an attacker.
If the error is actually on the sending side, then it will have most detailed error messages and the receiving side will have little or none. For example, if the sending side can't find its stash file the connection isn't ever attempted and the receiving side will have no record of the event.
Finally, there is always the possibility that you may discover a bug working with GSKit and MQ, or that you are trying to use features not relevant to version of MQ that you are working on. For this reason, it is always best to include a dspmqver -a in your question. If after all of this, you still can't get it to work, please update the question with the dspmqver -a output and the results of your further testing.
In summary
To sum up:
QMgr names like A_QM are perfectly valid.
First make sure that the QMgrs have picked up their new KDB files after changes by restarting the QMgrs or running REFRESH SECURITY TYPE(SSL).
Make sure to exchange certs in both directions every time.
Check the error logs on both sides starting with the side receiving the connection request.
Always include output from dspmqver -a when requesting help with GSKit, certs or TLS since the behavior varies by version and fix pack.
I'm trying to extract an ECDSA public key from my known_hosts file that ssh uses to verify a host. I have one below as an example.
This is the entry for "127.0.0.1 ecdsa-sha2-nistp256" in my known_hosts file:
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBF3QCzKPRluwunLRHaFVEZNGCPD/rT13yFjKiCesA1qoU3rEp9syhnJgTbaJgK70OjoT71fDGkwwcnCZuJQPFfo=
I ran it through a Base64 decoder to get this:
���ecdsa-sha2-nistp256���nistp256���A]2F[rUF=wXʈ'ZSzħ2r`M::WL0rp
So I'm assuming those question marks are some kind of separator (no, those are lengths). I figured that nistp256 is the elliptical curve used, but what exactly is that last value?
From what I've been reading, the public key for ECDSA has a pair of values, x and y, which represent a point on the curve. Is there some way to extract x and y from there?
I'm trying to convert it into a Java public key object, but I need x and y in order to do so.
Not all of characters are shown since they are binary. Write the Base64-decoded value to the file and open it in a hex editor.
The public key for a P256 curve should be a 65-byte array, starting from the byte with value 4 (which means a non-compressed point). The next 32 bytes would be the x value, and the next 32 the y value.
Here is the result in hexadecimal:
Signature algorithm:
00 00 00 13
65 63 64 73 61 2d 73 68 61 32 2d 6e 69 73 74 70 32 35 36
(ecdsa-sha2-nistp256)
Name of domain parameters:
00 00 00 08
6e 69 73 74 70 32 35 36
(nistp256)
Public key value:
00 00 00 41
04
5d d0 0b 32 8f 46 5b b0 ba 72 d1 1d a1 55 11 93 46 08 f0 ff ad 3d 77 c8 58 ca 88 27 ac 03 5a a8
53 7a c4 a7 db 32 86 72 60 4d b6 89 80 ae f4 3a 3a 13 ef 57 c3 1a 4c 30 72 70 99 b8 94 0f 15 fa
So you first have the name of the digital signature algorithm to use, then the name of the curve and then the public component of the key, represented by an uncompressed EC point. Uncompressed points start with 04, then the X coordinate (same size as the key size) and then the Y coordinate.
As you can see, all field values are preceded by four bytes indicating the size of the field. All values and fields are using big-endian notation.
My application is using SSL over SMTP.
But I faced a problem of extra byte at the end.
The packet which I recieved is as follows: (Hex dump of SSL Record packet)
17 03 01 01 00 9A 07 74 E3 4B E0 07 17 71 38 BF 29 7E 70
E9 14 CC B1 97 77 4C B9 AB A0 9F 88 7B D4 ED 14 8E 97 F2
5A BE 46 56 D4 12 BC 15 01 49 EE CE A1 ED 3F D3 6E 7F AA
DC 6B DF 41 11 74 7B 55 B8 D3 3E 8D EF 96 52 B0 BD 50 35
09 E7 2A FF 0E 39 58 C7 91 99 95 22 6F B0 73 57 28 B4 EA
C6 28 4C DC 5C DA 6C 31 FB 63 71 7D 08 F0 DD 78 C4 08 C5
27 90 04 C7 09 59 E4 83 F4 4D 9A 7B 65 E9 AF 38 44 B4 CD
9E 4D BE 80 0D 07 24 8D C3 79 99 DC 02 81 D7 97 21 16 0B
28 44 82 ED E4 5F E6 91 81 A5 28 C1 C8 92 60 36 4E DE 27
AF D0 2B EE FB 9D 12 9C 2B 4F 3F 29 F2 04 8F DC 21 39 4F
80 23 7E 78 3C A0 29 E0 67 E7 9F 90 B6 1F D4 08 63 3E CE
73 E1 17 72 8D B1 8C 3D A8 59 C0 0F 03 59 7A A6 5D F9 7A
40 57 D6 8D 94 48 93 BF D8 17 C6 70 79 36 13 D0 F1 D1 D2
69 D4 05 9D 67 86 6D E9 66 D0 83 4A D8 5E 20
The length of this packet as seen from SSL 3.1 protocol is 256 Bytes.
But there is one extra byte at the end (shown in bold at the end).
Due to this extra byte at the end, when next packet is being read, then this 20 is also read and causes error of SSL_R_WRONG_VERSION_NUMBER (I am using OpenSSL Library for SSL).
Next packet which I recieved is like (as per packet sniffer)
17 03 01 00 18 ...
But when next read is being done, OpenSSL reads packet as 20 17 03 01 .. which causes the error (since 17 03 is wrong version for 03 01)
I would like to know if this (extra byte at the end) is a part of SSL standard.
Please suggest me how to handle this case in OpenSSL. OpenSSL version is 1.0.0.
No. The extra byte is not as a part of SSL Standard.
As per SSL Standard (RFC 2246 for TLS 1.0, Latest is RFC 5246 for TLS 1.2) the record of SSL is as below:
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
} fragment;
} TLSCiphertext;
The fragment will be exactly of the length as specified by uint16 length member. So, the 20 must be getting inserted either incorrectly by the Server Implementation, or some other software in the middle is inserting it when the data is in network.
Openssl reads exactly the number of bytes as specified by uint16 length member which is why it doesn't read 20.
Some of the points which you can focus on are:
1. Does this happen with the first application data packet which is transferred immediately after handshake? (From the content type I assumed this packet dump is for application data)
2. Is this a random occurance? Do all connections with that particular server exhibit the same behavior?
3. You can try to get the dump of the packet sent at the Server to see if 20 is present when the packet is being sent at the Server side itself or it is getting added during it's flight.
4. Could there be a Firewall related problem? (I don't know about Firewall, so didn't give more details here)
Hope this helps!
I was bashing my head with this one today; finally resorted to this:
_sslStream.Write(merged, 0, merged.Length - 1)
Problem solved, move along!