I'm able to successfully encrypt and decrypt using dp:encrypt-string and dp:decrypt-data in datapower.
But how do I know the value of IV being used to encrypt by datapower?
Edit- First 16 bytes of the ciphertext generated by Datapower is the IV used. But how do I force datapower to use an IV of my choice over the random IV used by datapower?
Related
1.var hash = crypto.randomBytes(32);
2.var publickey = ecdh.setPrivateKey(hash,'hex').getPublicKey('hex');
then sha256 => ripemd160 => encode... => address
I know how the bitcoin address generated,but seems it just using ECDH to generate bitcoin address,but I saw lots of talk says it using ECDSA,I want to know where bitcoin using ECDSA and how bitcoin using cryptography to verify transaction and which crypto function using for signing transaction.
Thanks.
Bitcoin doesn't use ECDSA for its address generation, save from the fact that you can use the public key of the ECDSA to generate a Bitcoin address. Where the Elliptic curve is really used is in signing the transaction.
First you create a raw transaction with all the correct fields in, including the ScriptPubKey and then convert that to list of bytes. You then take the SHA256 of the transaction bytes and then SHA256 the result of the SHA256. This is the message digest and this is what you need to sign with the ECDSA private key to generate the SigScript. The SigScript however contains more than just the signed digest. First comes a digest length + 1 for the SIGHASH_CODE, then comes the signature itself, followed by sig hash code, then a length for the public key and finally the public key itself. Once you've concatenated all of these, that's your SigScript that needs to be inserted into the transaction. Obviously the entire SigScript is prefixed with a size, just like the SigPubKey. Lastly insert the size and the result and now you have a signed transaction you can broadcast.
I'm developing a simple secure data exchange between Server-Client and having some problems at the time of implementing AES.
I've already implemented the Shared Key exchange (with public key crypto) and it works fine. The idea in my head was (pseudocode):
SERVER
ciphertext = AES.encrypt(sharedKey,data)
send(ciphertext)
CLIENT
ciphertext = receive()
plaintext = AES.decrypt(sharedKey,ciphertext)
And voilà. When I tried to implement that, I first found that there was an IV. I first tried setting it to all zeros, like this:
self.cipher = AES.new(self.Kshared, AES.MODE_CFB, '0000000000000000')
while( there is data to send ):
ciphertext = self.cipher.encrypt(data)
self.sendData(ciphertext)
Then, in the Client:
cipher = AES.new(Ksecreta, AES.MODE_CFB,'0000000000000000')
while( there is data to receive ):
plaintext = cipher.decrypt('0000000000000000'+data)[16:]
This works fine for the FIRST message, but not for the rest. I assume my problem might has something to do with the IV but I have no idea. Plus, the first implementation I found used a salt to generate another key and also a random IV but the problem is that the client has no idea of which salt/IV is the Server using. I guess you could send that via public key crypto but I first want a simple working AES crypto.
Thanks.
For your decryption code, there's no need to prepend the cipher text with the IV. Have you tried just plaintext = cipher.decrypt(data)?
It's safe to transmit the IV in clear text. So you can just generate it randomly, then send it along with the ciphertext outside of the communication. Something like self.sendData(iv + ciphertext) and later iv = data[:16] and ciphertext = data[16:]
Another common thing to consider is encoding - some transport formats don't play well with sending raw byes (which can include NULL characters). It's common to encode the ciphertext into base64 for transport. If you need that, look into base64.b64encode and base64.b64decode
I've been struggling for multiple days now and cannot find any accurate example/tutorial on internet so now i'm here for help.
I have a Java application that creates an RSA Keypair. This Keypair is used to encrypt and decrypt a symmetric key. (but first to test i want to use a simple text string). After generating the keypair, the keys are encoded.
PublicKey publicKey = KeyFactory.getInstance("RSA").generatePublic(new X509EncodedKeySpec(pbKey));
and
PKCS8EncodedKeySpec ks = new PKCS8EncodedKeySpec(pvBytes);
Now i'm creating an application on iOS. And i would like to do the same in thing in iOS (C or Objective-C) using OpenSSL.
Can somebody help me with this?
I'm creating the keys like this
RSA_generate_key_ex(rsa, modulus, e, NULL);
Basically what you have there is a PKCS#8 encoding of the private key (ks). I.e. raw ASN.1.
I'll assume you write this out raw, encoded (Java asymmetric encryption: preferred way to store public/private keys, Decrypted string not the same as pre encrypted string).
So assumining that rsa is populated; and 'enc' is
const EVP_CIPHER *enc=NULL;
or more likely
const EVP_CIPHER *enc=EVP_aes_XXX_cbc();
where XXX is something like 128 bits you'd then call PEM_write_bio_RSAPrivateKey with something like:
PW_CB_DATA cb_data;
cb_data.password = passout;
cb_data.prompt_info = outfile;
BIO_set_fp(out,stdout,BIO_NOCLOSE);
if (!PEM_write_bio_RSAPrivateKey(out,rsa,enc,NULL,0,
(pem_password_cb *)password_callback,&cb_data))
goto err;
and that should be roughly it. Code can be lifted from apps/genrsa.c in any openssl source distribuition.
I use RSACryptoServiceProvider to encrypt some small blocks of data. For the solution I'm working on, it's important that if the same piece of source data is encrypted twice with the same public key, the result (the encrypted block of data) is not the same.
I have checked this with an example and it worked like I hoped. My question is now, if this behaviour is by design and guaranteed or if I have to add some random part to the source data for guaranteeing that data blocks with the same data can not be matched anymore after encryption.
Here is the example:
byte[] data=new byte[]{1,7,8,3,4,5};
RSACryptoServiceProvider encrypter = cert.PublicKey.Key as RSACryptoServiceProvider;
byte[] encryptedData = encrypter.Encrypt(data,true);
// encryptedData has always other values in, although the source data is always
// 1,7,8,3,4,5 and the certificate is always the same (loaded from disk)
The concrete question is for .net but maybe the answer can be given in general for all RSA-implementations if it is by design?
The text-book RSA encryption algorithm is deterministic:
ciphertext = plaintext ^ encryption-exponent mod modulus
(Here ^ is integer exponentiation, mod the remainder operation.)
But as you remarked, this does not provide a good security guarantee, as an attacker which can guess the plaintext can simply verify this guess by encrypting it himself and comparing the results.
For this reason, the official RSA specifications (and also all implementations used in practice) include some (partly random) padding, so we don't actually encrypt plaintext, but pad(plaintext):
ciphertext = pad(plaintext) ^ encryption-exponent mod modulus
Decryption:
plaintext = unpad( ciphertext ^ decryption-exponent mod modulus )
Only with this padding RSA is actually a secure encryption scheme.
A similar padding is also used for RSA signatures, to avoid easy forging of signatures.
I am looking for a commutative cipher - that is
E(K₁,E(K₂,P)) = E(K₂,E(K₁,P))
but is not associative - that is
E(K,P) ≠ E(P,K)
That rules out XOR, which otherwise would have been ok.
A symmetric cipher would be preferable, but an asymmetric cipher would work too.
The basic protocol I want to implement is:
Alice has a list of tokens (32-bit integers) and she encrypts each token with the same key (K0)
Alice sends the list of encrypted tokens to Bob
Bob randomises the list, encrypts each token with a separate key (K1 - Kn), labels each token and returns the list to Alice.
Alice decrypts each token with K0, leaving her a list of tokens, each encrypted with a separate key (K1 - Kn)
Sometime later, Bob sends Alice a key for a specific label (Kx)
Alice decrypts the token with Kx giving her the plaintext for the token labelled x
Bob may see the plaintext, so he must not be able to derive K0 from it given the information he was previously given.
Can someone suggest a cipher I can use and also point me to an implementation of that cipher?
I have an understanding of cryptographic protocols and applications but I don't really grok the mathematics of most of the ciphers out there. Step-by-step mathematical guides would be ok though.
I plan to implement this in Clojure so any Java libraries are also good. However, any code is good because I understand code.
It sounds like you're trying to implement "Mental Poker" (or if not, you should look up the research into it, since it's analagous to your problem).
The SRA algorithm has the properties you desire. It's a bit hard to find information on, but it is essentially just RSA except that both the e and d exponents are kept secret. Trivially:
(Pe1)e2 == (Pe2)e1
below refers to my hobbiest solution using my own cipher program in C#. program and source are free and available.
Remember the 'locked box puzzle' recounted on an SECURITY NOW podcast?
here's the episode...
Episode #33 | 30 Mar 2006 | 43 min.
Symmetric Block Ciphers
https://www.grc.com/sn/sn-033.txt
Steve says...
...Leo and I answer last week's Puzzler/BrainTeaser which explored the idea
of using two private
one-time pad "keys," like two padlocks, to securely convey a message between
two parties, neither of
whom would have the other's key. Then we continue our ongoing tour of
fundamental crypto technology by
describing the operation of Symmetric Block Ciphers...
Steve and Leo agreed that an eavesdropper seeing ALICE's cipher text before
and after encryption could
XOR both together and derive her secret key.
However, if a complex, commutative cipher which doesn't use simple XORing
to encrypt is used then I
think the key exchange would be secure and the key exchange would work.
for example...
BOB encrypts msg with his key.
ALICE encrypts BOB's encrypted above msg with her key.
ALICE sends above encrypted msg back to BOB.
BOB decrypts ALICE's above msg with his key.
BOB sends above to ALICE.
ALICE decrypts above with her key.
ALICE can now read BOB'S original decrypted cipher text and they didn't need
to exchange keys.
An eavesdropper attack will not work if the algorithm is not a simple
'xor'ing of plain text and key.
this cipher is a commutative , complex algorithm.
starting with notepad text file containing one character, an 'm'.
m is hex 6d 01101101.
 is hex c2 11000010 is 'm' encrypted by bob and then sent to alice.
ø is hex d8 11011000 is alice's encryption of 'Â' which bob decrypts to '£'
and sends to alice.
£ is hex a3 10100011 which alice decrypts to 'm' with her key.
m is alice decrypt result
an eavesdropper sees  alice's msg before her encryption.
the eavesdropper sees ø alice's msg after her encryption.
the eavesdropper xors  and ø.
11000010 'Â'
11011000 'ø'
00011010 the eavesdropper's xor result = 1a in hex.
if an eavesdropper attack worked he would have found 'E' hex 45 01001001
which is first letter of
alice's key.
this seems a simpler key exchange than PGP etc. All that's needed is that
both parties use the same
crypto program and agree on an authenticator.
I confess to being a hobbiest. If anyone wants the WINDOWS C# .NET program
and/or the source code for the cipher they
may have it/them.
below is example with longer, random keys.
PLAIN TEXT
this is a test.
BOB'S KEY
kZtOfS0kKqcRLjTNPh7OjcJKZZFLjmm5OVm02YlrBQN0zI9SxOD1zJjQcpetUbX
BOB'S CIPHER TEXT TO ALICE.
1IÎ.8Ío#"ëìAùJ'
ALICE'S KEY
O1yfuV7MpX3n4wtefUhr6YctRaeCcrrzH7LqLNRUQCMVZuL5Mr0Bw3qMeIT92hg
ALICE'S CIPHER TEXT TO BOB
µRÖ³#ïÓO,fzkÆaå
BOB DECODES ALICE'S ABOVE WHICH = BELOW.
øqqøð<ª>P¸&#<,
AND SENDS ABOVE BACK TO ALICE WHICH ALICE DECODES YIELDING...
this is a test.
I'm doing something similar and I'm using AES in OFB (output feedback) mode. In this mode, an IV (publicly known random value) is encrypted with AES using some key. The output of this is then XORed with your data. The output (before being XORed with the data) is then encrypted again to get another output to XOR with more data. This is not only commutative but reciprocal in the sense that the encryption and decryption algorithms are identical.
http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Output_Feedback_.28OFB.29
I know the question was asked long ago, but nobody seems to have suggested Massey-Omura, so here it goes. It satisfies the original requirements exactly. The original description (also adopted in Wikipedia) used the multiplicative group of GF(2^m), but any secure group (like elliptic curves) will do.
Here is a page with commutative encryption algorithms :
https://xianmu.github.io/posts/2018-09-19-commutative-encryption.html