I am implementing my own version of RSA-OAEP with SHA-256. I want to test it by comparing it to the output of the Cipher class in Java using RSA-OAEP and SHA-256. According to PKCS #1, RSA-OAEP requires a label, which by default is an empty string. However, I can't find a way to input a label in the built-in class. My implementation seems to work correctly for both encryption and decryption, but Cipher class produces different output. Is there a default label which the Cipher class uses?
What is called label L in PKCS1v2.1 RSAES-OAEP was called encoding parameters P in v2.0; see the description of pSourceAlgorithm in A.2.1. The Java API keeps the old terminology, presumably for compatibility, and the default is indeed an empty octet string, implemented in Java as a byte array of length 0. See https://docs.oracle.com/javase/7/docs/api/javax/crypto/spec/PSource.PSpecified.html . Note that even when P-call-me-L is empty, its hash which goes in DB before masking is not empty.
When you say 'different output', you do realize that OAEP is randomized (in a way that provably does not leak information to the adversary) and every encryption of the same plaintext should produce a unique ciphertext, but all of them should decrypt back to the same plaintext, right?
Related
Let's say that I have three null bytes, and I base64-encode them:
(Python)
import base64
import hashlib
foo = b'\xd3\x4d\x34'
foo_b64 = base64.b64encode(foo)
print(foo_b64)
# Outputs:
# 0000
foo_sha256 = hashlib.sha256(foo).hexdigest()
print(foo_sha256)
# Outputs:
# 0e10e03565f4664a05c3bc63ed35df3e1a9cb2568371db4f12b66c728943f802
Let's say I put that base64 string in a Terraform config:
locals {
foo_b64 = "0000"
}
In Terraform, I need to find a way to get the SHA256 hash of the raw value of foo, i.e. in Terraform I need to generate that same hash (0e10e03565f4664a05c3bc63ed35df3e1a9cb2568371db4f12b66c728943f802).
I've gone through the Terraform functions and can't seem to find something that works.
sha256(local.foo_b64) gives the SHA256 hash of the base64 string, not the raw bytes that it encodes.
sha256(base64decode(local.foo_b64)) throws an error: Call to function "base64decode" failed: the result of decoding the provided string is not valid UTF-8.
Is there any way to achieve this?
The Terraform language has a string type that is defined as containing Unicode characters rather than bytes, so anything which creates a string from raw input requires that input to be UTF-8 encoded Unicode characters.
This means that it isn't possible in general to pass raw binary data from one function to another. For situations where a Terraform configuration does need to work with small binary objects, the convention is to pass them around as base64 encoding, but that works only if your configuration treats the base64 data as opaque, never needing to decode it, because there is no way to represent the decoded form.
Given that, I think in order to solve your underlying problem with Terraform you will need to take a different approach. For example, perhaps whatever external system is generating the base64 string could also generate the SHA256 checksum of it, which Terraform would then also treat as opaque rather than trying to calculate it directly. You've presented one technical solution to an unstated problem here, so I can't be any more specific about what other options might be, but the main requirement would be that Terraform will just pass through the (base64-encoded) binary data verbatim to a provider and never interrogate it directly itself.
How can this be done in iText? I have a PDF with a signature from a client. I need to add an ocsp response to unsigned attributes.
I know how to change the signature itself using
org.bouncycastle.cms.CMSSignedData.replaceSigners(...).getEncoded()
but I don't know how to replace PdfName.CONTENTS in the PDF using new PdfString(newSignature).setHexWriting(true). If I use this code:
PdfDictionary other = new PdfDictionary();
other.put(PdfName.CONTENTS, new PdfString(newSignature).setHexWriting(true));
dicSignature.merge(other);
where dicSignature is the dictionary which contains the signature, then the signature (when the document is opened in Adobe Reader) is broken.
When iText manipulates a document using aPdfStamperin normal mode, it can (and often does) re-arrange the existing PDF objects. This obviously breaks the hash value of any existing integrated signature. Furthermore the byte ranges which would have to be signed, change. This most likely is your problem.
When iText manipulates a document using aPdfStamperin append mode, it leaves the PDF as is and only appends its additions and changes. While this in general is the way to go to keep integrated signatures from breaking, you cannot change the content of a signature this way because there are stricter rules concerning embedding signatures than for PDFs in general. Switching to append mode, therefore, would not fix your problem.
Thus, iText has an explicit method doing a signature insertion without otherwise changing the PDF:
MakeSignature.signDeferred(PdfReader reader,
String fieldName,
OutputStream outs,
ExternalSignatureContainer externalSignatureContainer)
throws DocumentException, IOException, GeneralSecurityException
Its name is due to the fact that this method originally is intended for the use case of deferred signing, i.e. first preparing the PDF for signing (i.e. adding all dictionaries and other necessary structures required to hash the byte ranges, including leaving a gap into which a signature container eventually shall be injected), calculating the hash value, and sending it to some other service while storing the prepared PDF locally. As soon as that other service returns the signature, the prepared PDF is located and the retrieved signature is inserted into it using this method.
The only difference to your use case is that there already is a signature in the gap. That signature, though, will be overwritten by your updated one when using signDeferred.
Having said all this, you may be in for a surprise if you expect that after you add an ocsp response to unsigned attributes, Adobe Reader uses these information for verification. In the context of integrated PDF signatures according to ISO-32000-1, section 12.8.3.3 PKCS#7 Signatures as used in ISO 32000,
the PKCS#7 object should contain [...] Revocation information as an signed attribute (PDF 1.6): This attribute may include all the revocation information that is necessary to carry out revocation checks for the signer's certificate and its issuer certificates. Since revocation information is a signed attribute, it must be obtained before the computation of the digital signature. This means that the software used by the signer must be able to construct the certification path and the associated revocation information. If one of the elements cannot be obtained (e.g. no connection is possible), a signature with this attribute will not be possible.
Can anybody explain me about this thing?
X-GWT-Permutation:1F79347D29BC07C95FC8B3A262D5DC8E
i have tried decoding some of the strings using Base 64.
i am using the following base to decode strings like bwR2, bwSo, bwSn, bwTU...
Base = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789$_
i got this string from this type of Request Payload Header:
7|0|10|https://www.bosscapital.com/app/Basic/|B8CC86B6E3BFEAF758DE5845F8EBEA08|com.optionfair.client.common.services.TradingService|prepare2OpenPosition|J|D|java.lang.String/2004016611|I|1.11427|0|1|2|3|4|11|5|5|5|5|6|6|7|7|8|7|8|BHLE|bwRF|E|Po|1.11427|1.11427|9|0|49|10|1|
The X-GWT-Permutation header references a GWT permutation's strong name (the strong name is an MD5 of the generated JavaScript code out of the JavaToJavaScriptCompiler, before it gets passed to the "linker").
The value isn't actually checked, only the presence of the header (as a partial countermeasure against XSRF).
The GWT-RPC wire protocol is described in https://drive.google.com/open?id=1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU
An existing coldfusion website is to be converted to dot net.
In the coldfusion code, the password is hashed using its hash() function with no algorithm:
SomePassword = '#hash(fldPassword)#'
I found this document, saying the default encryption is
CFMX_COMPAT: Generates a hash string identical to that generated by
ColdFusion MX and ColdFusion MX 6.1 (default).
There are some articles actually telling me how to decrypt.
According to Macromedia, The ColdFusion Encrypt function uses an
XOR-based algorithm that utilizes a pseudo random 32-bit key based on
a seed passed by the user as a parameter to the function. The
resulting data is UUencoded.
You'll need to uudecode the encoded value first
http://www.eggheadcafe.com/printsear...asp?linkid=351
and then XOR it using the key it was encrypted with.
http://www.java2s.com/Code/CSharp/La...deamessage.htm
If you dont have the key - your wasting yuor time.
But, how to make it work? I don't think there is any key. All I can see is '#hash(fldPassword)#'. Please help. Thanks.
There are some articles actually telling me how to decrypt.
Hashing and encryption are not the same thing. Encryption can be reversed. You can recover the original value if you have the right key, etectera. Whereas hashing is a one way trip. Once hashed, the original value cannot be recovered. (Well .. in theory. Some of the weaker hashing algorithms have been broken.) So you cannot "decrypt" a hashed value. But you can duplicate the obfuscated result string.
I found this document, saying the default encryption is CFMX_COMPAT
Actually it refers to the default algorithm. However, I am not so sure that description is correct. (Edit: As Rasmus correctly points out, it does say the default is MD5) However, CF9/7 default to MD5 anyway. Even when the algorithm is CFMX_COMPAT. So in either case, a simple MD5 hash in C# would give you the same result.
ie These all produce identical results ie 098F6BCD4621D373CADE4E832627B4F6.
#hash("test")#
#hash("test", "cfmx_compat")#
#hash("test", "md5")#
If I read the documentation correctly, CFMX_COMPAT hashing is just MD5.
So:
byte[] hash = MD5.Create().ComputeHash(fldPassword);
It should be easy to verify if you have access to a ColdFusion installation.
I use following class to encrypt/decrypt my texts.
http://code.google.com/p/iphonebits/source/browse/trunk/src/Encryption/NSData-AES.m?r=2
This works perfectly. But when I decrypt the encrypted text with an invalid key (any one other than encryption key) this returns some text and its not in the actual length of the decrypted text. What can be the reason (is this supposed to return nil)? Is this the better way? Does libraries supposed to return errors for invalid decryption keys? Is it a must or not?
Thank you
Well, the algorithm will not know if the key that you are providing is the right one. To know if the key is right the algorithm would have to have it's copy, which is unsafe. Although it could have the copy of it's hash, but that would still apply that the encryption and decryption algorithms would work for only one key. Your current decryption accepts the key and put's it to work in the decoding algorithm. The result should reflect the original text but if the key was wrong it will give you the text generated according to the wrong key. It's all working properly.