D/DP/DQ Parameters in RSA Cryptography - encryption

I see some parameters in RSA cryptography such as D / DP/ DQ P and Q what this parameters really do is it some kind of padding for the cipher text?

These parameters are used to speed up the private key operations using the Chinese remainder theorem.
The wikipedia article on RSA describes how this is done.

Related

RSA: plain text to cipher text

I'm trying to solve the following question (see below)
enter image description here
My understanding what in order to go encrypt the plain text (and get the cipher text). I must compute 9^15 mod 2 to get the cipher text? How is the answer 6?
Many thanks in advance!
You are confusing the modulus n and the public key e.
In your case, the RSA modulus is 15 and the public exponent is 2, and, in general, we write the public key is as a tuple (n,e)=(15,2)
now, RSA (textbook) encryption calculated as m^e = mod n; as a result
9^2 = 6 mod 15
see at WolframAlpha
Note: RSA encryption needs padding to be secure against some attacks.
as James noted in the comment, this cannot be RSA.
phi(15) = (3-1)*(5-1) = 8.
The inverse of 2 doesn't exist in mod 8. therefore there is no private key. Interestingly, in this case inverse of 3,5,7 mod 8 are also 3,5,8, respectively.
The 2 suggests that this is actually Rabin Cryptosystem.

How to extract partial cypher text with openssl or gpg?

I have edited the question after the clarification of Marcus in his commment.
I have a question and I am unable to find the answer using Google.
I know that in S/MIME encryption or with GnuPG/Enigmail, the plain text is first encrypted with a symmetric algorithm such as AES or 3DES or IDEA, and the password used for the symmetric encryption is encrypted with an asymmetric algorithm (RSA).
MY question, is possible using gpg or openssl to knows the symmetric algorithm used and do a partial encryption, in other words I would to decrypt only the asymmetric algorithm to view the password used for the symmetric encryption.
I'll try to explain it using math notation :
T -> plain text
s -> the symmetric algorithm encryption
p -> the password used by symmetric encryption function
a -> the asymmetric encryption function (RSA), it merges cyphered text and other data too.
k -> my public key
When someone send me a message I receive C and, since I have my private key, I decrypt it using it
C = a(p, k) + s(T, p)
I would to know s(T, p) and p, if possible.

decryption using hill cipher technique

In hill cipher we use a key matrix to encrypt a plain text.the same way we find inverse of the key matrix to decrypt the cipher text.finding the inverse of the key matrix in the decryption side makes the decryption process a bit complex.so is there any way to decrypt the cipher text with the same key matrix without finding the inverse of the key matrix in the decryption side?
You can, but then you need to solve a system of linear equations for each text block. Since this is almost as expensive as inverting the matrix, it is not a useful approach.

What is the difference between DSA and RSA?

It appears they are both encryption algorithms that require public and private keys. Why would I pick one versus the other to provide encryption in my client server application?
Check AVA's answer below.
My old answer seems wrong
Referring, https://web.archive.org/web/20140212143556/http://courses.cs.tamu.edu:80/pooch/665_spring2008/Australian-sec-2006/less19.html
RSA
RSA encryption and decryption are commutative
hence it may be used directly as a digital signature scheme
given an RSA scheme {(e,R), (d,p,q)}
to sign a message M, compute:
S = M power d (mod R)
to verify a signature, compute:
M = S power e(mod R) = M power e.d(mod R) = M(mod R)
RSA can be used both for encryption and digital signatures,
simply by reversing the order in which the exponents are used:
the secret exponent (d) to create the signature, the public exponent (e)
for anyone to verify the signature. Everything else is identical.
DSA (Digital Signature Algorithm)
DSA is a variant on the ElGamal and Schnorr algorithms.
It creates a 320 bit signature, but with 512-1024 bit security
again rests on difficulty of computing discrete logarithms
has been quite widely accepted.
DSA Key Generation
firstly shared global public key values (p,q,g) are chosen:
choose a large prime p = 2 power L
where L= 512 to 1024 bits and is a multiple of 64
choose q, a 160 bit prime factor of p-1
choose g = h power (p-1)/q
for any h<p-1, h(p-1)/q(mod p)>1
then each user chooses a private key and computes their public key:
choose x<q
compute y = g power x(mod p)
DSA key generation is related to, but somewhat more complex than El Gamal.
Mostly because of the use of the secondary 160-bit modulus q used to help
speed up calculations and reduce the size of the resulting signature.
DSA Signature Creation and Verification
to sign a message M
generate random signature key k, k<q
compute
r = (g power k(mod p))(mod q)
s = k-1.SHA(M)+ x.r (mod q)
send signature (r,s) with message
to verify a signature, compute:
w = s-1(mod q)
u1= (SHA(M).w)(mod q)
u2= r.w(mod q)
v = (g power u1.y power u2(mod p))(mod q)
if v=r then the signature is verified
Signature creation is again similar to ElGamal with the use of a
per message temporary signature key k, but doing calc first mod p,
then mod q to reduce the size of the result. Note that the use of
the hash function SHA is explicit here. Verification also consists of
comparing two computations, again being a bit more complex than,
but related to El Gamal.
Note that nearly all the calculations are mod q, and
hence are much faster.
But, In contrast to RSA, DSA can be used only for digital signatures
DSA Security
The presence of a subliminal channel exists in many schemes (any that need a random number to be chosen), not just DSA. It emphasises the need for "system security", not just a good algorithm.
Btw, you cannot encrypt with DSA, only sign. Although they are mathematically equivalent (more or less) you cannot use DSA in practice as an encryption scheme, only as a digital signature scheme.
With reference to man ssh-keygen, the length of a DSA key is restricted to exactly 1024 bit to remain compliant with NIST's FIPS 186-2. Nonetheless, longer DSA keys are theoretically possible; FIPS 186-3 explicitly allows them. Furthermore, security is no longer guaranteed with 1024 bit long RSA or DSA keys.
In conclusion, a 2048 bit RSA key is currently the best choice.
MORE PRECAUTIONS TO TAKE
Establishing a secure SSH connection entails more than selecting safe encryption key pair technology. In view of Edward Snowden's NSA revelations, one has to be even more vigilant than what previously was deemed sufficient.
To name just one example, using a safe key exchange algorithm is equally important. Here is a nice overview of current best SSH hardening practices.
And in addition to the above nice answers.
DSA uses Discrete logarithm.
RSA uses Integer Factorization.
RSA stands for Ron Rivest, Adi Shamir and Leonard Adleman.

For the Diffie-Hellman prime and generator, what key length should I use?

In the code below, from the Crypto++ wiki, is 128 the number I really should be using?
CryptoPP::AutoSeededRandomPool arngA;
CryptoPP::RandomNumberGenerator& rngA = *dynamic_cast<CryptoPP::RandomNumberGenerator *>(&arngA);
CryptoPP::DH dhA(rngA, 128);
CryptoPP::Integer iPrime = dhA.GetGroupParameters().GetModulus();
CryptoPP::Integer iGenerator = dhA.GetGroupParameters().GetSubgroupGenerator();
Integer factorization and discrete logarithm over Z/(pZ) are roughly equally difficult. Therefore the size of the modulus for Diffie-Hellman should be about the same size as you would choose for an RSA modulus. If you are comfortable with a 1024-bit RSA key then you can also be comfortable with a 1024-bit Diffie-Hellman key.
It is not easy to tell if key sizes in crypto++ are measured in bits or bytes.
As Sebastian points out dhA(rngA, 128) may indeed generate a 128 bit Diffie-Hellman key, which would be too small. Going through the code it looks like this is indeed the case.
The size of the generator iGenerator does not affect the security of Diffie-Hellman. (I.e. iGenerator = 2 could be perfectly fine)

Resources