I read a book called "computer networking: A top-down approach". It talked about how PGP creates an email message between Alice and Bob to maintain confidentiality, integrity, and authenticity. Let me define some terminology and the procedure at the very high level:  m :              email message H() :            cryptographic hash function Ka_priv_sign() : signing using Alice's private key || :             contacternation Ks :             session key Ks_enc():        encryption using session key Kb_pub_enc():    encryption using bob's public key blob :           The final data blob Alice sends to Bob.   To send an email to Bob, Alice first signs the message with her private key:  m || Ka_priv_sign(H(m))   Alice then encrypt the message and signature  blob = Kb_pub_enc(Ks) || Ks_enc(m || Ka_priv_sign(H(m)))    Alice will send this final blob to Bob.   The cryptography seems to have a problem here since digital signature is applied before encryption and encryption does not provide data integrity. I think the right order of operation should be:  Alice first encrypts the message with the session key and encrypt the session key with Bob's public key:  Kb_pub_enc(Ks) || Ks_enc(m)   Alice then signs the encryption results after hashing them:  blob' = Kb_pub_enc(Ks) || Ks_enc(m) || Ka_priv_sign(H(Kb_pub_enc(Ks) || Ks_enc(m))))    Questions:  Is PGP still using the way that the textbook describes today? Do you think my construction is better?
61435
Frequently, we want to send messages that are (a) encrypted, so passive attackers can't discover the plaintext of the message, and (b) signed with a private-key digital signature, so active attackers can't make Alice think that a message came from Bob when it didn't. Is it better to (a) generate the digital signature from the (hashed) plaintext, and then encrypt a file containing both the plaintext message and the digital signature? Or is it better to (b) encrypt the message first, and then generate a digital signature from the (hashed) encrypted file? Or (c) combine encryption and public-key digital signatures in some other way? A closely related earlier question (  ) seems to focus on symmetric-key MAC authentication. As , Do the same issues with (symmetric-key) MAC-then-encrypt apply to (public-key) sign-then-encrypt?
63536
It seems that even in MAC-then-encrypt systems like SSL, something like HMAC is used rather than a plain hash. Why?   Suppose we use some stream cipher; then why can't we use $Encrypt(m | H(m))$ as the MAC-then-encrypted version of the message? Assuming no bad relations between $Encrypt$ and $H$, what are the possible weaknesses? It seems that in this case we are encrypting the hash with part of a secretly keyed stream cipher keystream, and the hash is secure; does this not fulfil an approximation of the ideal MAC?  This must be somehow bad, since no secure protocol seems to use it. Why?
104204
If we encrypt a message twice with symmetric key $k_1$ first and then $k_2$ like $E_{k2}\{E_{k1}\{m\}\}$ , ideally we should decrypt with $k_2$ first and then $k_1$ but is it possible to decrypt with $k_1$ and then with $k_2$ ?  Using any of the AES Modes preferably ?
28776
This is theoretical question. I'd like to know if it's possible (and what are eventually the consequences), not that I'm going to do it in one of my projects. ;)  The first hashing functions created were based on a symmetric cipher (just like the first Unix crypt was based on DES). The idea was simple. Use the password as key to encode a constant.  I'd like to know if it's still possible to convert any modern symmetric cipher into a hashing function (and second question: into a cryptographic hashing function). Is it possible (easier) to guess the key, when you have an encoded and decoded messages?
4208
I was just looking at some , specifically at Hash_DRBG. I read briefly through the algorithm, and even though it is not overly complex, it still seems unnecessary to me. I asked myself how I would implement a (cryptographically secure) PRNG on top of a Hash algorithm (SHA256 or SHA512), what came up is:  Idea one:    Obviously this can only provide half the "strength" of the hash  Initialization: state = hash(seed); Iteration: output = first_half_of(state); state = hash(state); Reseeding: state = hash(state || new_seed)   Idea Two:  Maybe with a separate counter  Initialization: state = hash(seed); Iteration: output = hash(state); ++state; Reseeding: state = hash(state || new_seed)   Now, these two "schemes" seem safe to me, I'm a complete crypto noob though. The point is that I don't think that I'm the first one to think of these very basic PRNGs, and I'd like to understand the reason for NIST not to choose something similar in their recommendations. Do these PRNGs have some (obvious?) weaknesses? (If not, is there something known about after how many iterations they should be reseeded?)
119167
One-Time Padding is (theoretically) perfect encryption algorithm. Let's assume that these problems are solved:   Fast generation of independent and identically distributed random variables Perfect key distribution system Key only used once. Key destroyed after use, without side channels that would allow any non-trusted third party to attain any key bits.   However, for modern information exchange, it is not sufficient to encrypt information (this is against Eve). In addition to encryption, it is necessary to also protect   integrity (this is against broken phone or cable) and message authenticity (this is against Mallory).   Some recommendations in cryptography recommend to use security level similar for encryption keys and message authenticity keys (i.e. use 128-bit encryption key and 128-bit MAC key). For MAC tag, it is common convention for HMAC or to use at most half of the MAC key length as the output length. Some other algorithms use full block length of the function.  For information theoretic authentication tag security, I would expect that in order to transfer message with length $N$ bits, I would need at least another $N$ bits to transfer "authentication tag" matching with the message.  Choices for Integrity or Authentication  Here are some of example schemes:   Double the bits. I.e. when instead of 0110, process plaintext 00111100 with OTP. This'll eat twice as much key material than OTP, but will protect against any single bit errors, and many of other errors, because it is easy to check at the recipient. (If only worrying about integrity.)  Process concatenation of $P$ (plaintext) and $T$ (mac tag) via OTP. There is problem how to calculate $T$. My first idea would be to use some operation on binary Galois Fields $GF(2^n)$, such as multiplication $C * C$ and use OTP to send that "checksum". (Only for integrity, but detects integrity problems with larger probability than option 1.)   Any suggestions how to efficiently calculate $T$? Are there any schemes which would provide usual security without key length $K=2N$? Are some of preconditions incorrect?  For authenticity it would appear that these are valid options:  3. encrypt-then-mac with an information-theoretically secure mac.  4. mac-then-encrypt with an information-theoretically secure mac.  What would be suitable information-theoretically secure mac for implementing alternative 3? Alternative 4 uses more key material than alternative 3. Are there any situations where alternative 4 would be profitable over alternative 3?  Previous Questions About The Field  You could think of this question as sort of add-on question to: ""
35864
What is the difference between encrypting some data vs signing some data (using RSA)?    Does it simply reverse the role of the public-private keys?    For example, I want to use my private key to generate messages so only I can possibly be the sender.  I want my public key to be used to read the messages and I do not care who reads them.  I want to be able to encrypt certain information and use it as a product-key for my software.  I only care that I am the only one who can generate these.  I would like to include my public key in my software to decrypt/read the signature of the key.  I do not care who can read the data in the key, I only care that I am the only verifiable one who can generate them.  Is signing useful in this scenario?
15506
It's been over 30 years since Rivest, Shamir and Adleman first  described their algorithm for public-key cryptography; and the intelligence community is thought to have known about it for around 40 years&mdash;possibly longer.  It's fair to assume that, during those 40 years, certain three-letter organisations have employed their vast resources toward "breaking" RSA.  One brute-force approach may have been to enumerate every possible key-pair such that, upon encountering a message known to be  encrypted with a particular public-key, they need merely lookup the associated private-key in order to decrypt that message.  Signatures could be forged similarly.  How reasonable is this hypothesis?  How much computing resource would have been required over those 40 years to enumerate every possible {1024,2048,4096}-bit key-pair?  I think it best to avoid discussion and leave the question of whether the spooks could have harnessed such resource as an exercise to the reader.
22445
In (EC)DSA as per , the message to sign is first hashed. Imagine that we skip this hashing stage, instead put the message where the hash was, and constrain the size of message $h$ to the original hash's output width $N$ bits. The resulting scheme is vulnerable to (at least) these existential forgeries ($q$ is the multiplicative group order):   any signature for message $0\le h&lt;2^N-q$ is also valid for message $h+q$; a valid signature for messages $h=0$ and $h=q$ is easy to obtain: in DSA, $(r,s)$ with $r=s=y\bmod q$ does the trick, where $y$ is the public key; there's an analog with , which $r=s=x_A\bmod q$, where $x_A$ is the $x$ coordinate of the public key, and $q=n$.   Are other attacks possible? In particular, does temporary access to a signing oracle allow a total break (key extraction or other mean to sign any message)?    The question is of direct interest when one wants to lower the communication overhead between a signing device and a host using it to (EC)DSA-sign large messages: can we fully offload the hash computation to the host? I believe that holds (and as noted in comments, that seems to be practice), but can we demonstrate that? If not, how can we safely offload most of that computation, without breaking standard conformance?
61216
I am trying to come up with what could maybe be a novel algorithm for an application I am writing. Client A has a file fA. Client B has file fB. Each party is untrustworthy and will try to rip off the other party. Client A wants the fB and client B wants fA.  How can I make an algorithm were it is not possible for them to screw the other player.  For example:     A encrypts fA and send the file to B.     B encrypts fB and sends it to A.  Now, both A and B have an encrypted version of the file they want.  How can they both share the decryption key at the same time... or what?   Is this even possible? This is breaking my mind.  Since each client will try to rip the other party, Client A cannot send the file fA to client B and expect client B to send back its file. If client A sends it first "with no guarantees", client B will simply run off with the file.  In real life a person holds the pot in one hand, the other holds the cash in the other. They both trade each hand at the same time. The guy with the cash now ends up with the pot and vice versa. How can I do something similar with computer bits. (client A and B are on a network at different locations).  EDIT: Please note that each party has a hash of the file they are supposed to get. Therefore, the parties cannot send a junk file to the other guy whit-out him knowing. A trusted third party will provide the hash.
101847
I have been reading about . I was wondering if this attack is feasible while signing with RSA and, if yes, how?    Also, how this kind of attack is applied with DH?   Talking about timing attacks in general, in which way AES is affected and how to solve it? (I mean, with RSA the "problem" is at multiplication level, while for AES where is the problem that makes the cipher implementation key or data dependent?)
70387
Studying for CISSP these choices seemed limited:     What is the advantage of digital signatures over message authentication codes?         Digital Signature provides integrity verification while message authentication code does not   Digital Signature provides confidentiality while message authentication code does not   Digital Signatures provide authenticity while message authentication code does not   Digital Signatures works faster than message authentication codes      Using the following chart as a reference, I'm leaning towards #2, but none of the choices really fit properly…  Cryptographic primitive | Hash |    MAC    | Digital Security Goal           |      |           | signature ------------------------+------+-----------+------------- Integrity               |  Yes |    Yes    |   Yes Authentication          |  No  |    Yes    |   Yes Non-repudiation         |  No  |    No     |   Yes ------------------------+------+-----------+------------- Kind of keys            | none | symmetric | asymmetric                         |      |    keys   |    keys   Hopefully an expert here can clarify.
91405
I am studying about blockchain and have been focusing on encryption protocols that allow authentication. The digital signature of public and private key seems solid, I have focused on the algorithm ED25519.  But in some places, some people say about not exposing the public key because through the public key and signature it would be possible to derive the private key. Some say that quantum computers will easily accomplish this task.  At first, I thought the reason for the bitcoin addresses was to make the public key "human-readable." But I see that there are some security points having a public key hash.  So I have some doubts:   Is it really a risk of exposing the public key without any treatment? If so, what are the alternatives? How does bitcoin, for example, validate the transaction signature with a public key hash and not the public key itself? (After all, it would be "impossible" to reverse a sha256 hash to its origin)
37042
From what I know, the HMAC constructions has two strength:   It's resistant to length extensions Since the key is consumed before the message, the attacker does not know the initial state, preventing simple collision attacks.   But the simple construction $ \mathrm{Hash}(\mathrm{Hash}(\mathrm{key} ∥ \mathrm{message})) $ would offer those properties too.  HMAC on the other hand uses the more complicated construction $ \mathrm{Hash}((\mathrm{key} ⊕ \mathrm{opad}) ∥ \mathrm{Hash}((\mathrm{key} ⊕ \mathrm{ipad}) ∥ \mathrm{message})) $. I assume the more complicated construction of HMAC is required for some security proof, but I don't immediately see why.  For SHA-3 candidates, Hash(key||message) is claimed to be secure, since they're resistant to length extensions, without consuming the key twice. I believe Skein even has some security proof for a very similar mode.  So why does HMAC need to inject the key twice?
73738
Let's say I would like to communicate with my friend using asymmetric/public-key encryption, e.g. RSA.  (Note: I do realize that in practice this is done through an intermediate symmetric key, but this question assumes we only use asymmetric encryption.)  Say I try to do this: I slice up my data into 2n-byte blocks (padding with zeros [edit: padding appropriately] if necessary), append the block index to the block (to prevent the same plaintext from turning into the same ciphertext), then use my friend's public key to encrypt each block separately.  Is this a secure scheme, or does the fact that I'm re-using the key make it susceptible to some kind of attack? If so, is it used in practice in any existing algorithms? If not, is there any way to make it safe, aside from using a symmetric key?
74295
Alice and Bob are going to follow the protocol below.  Are there any crypto-constructions to help Bob verify the correctness of the answer he gets?:   Alice encrypts a set of numbers using some cryptosystem and a secret key (e.g. Paillier crypto-system). Bob multiplies the ciphertexts to obtain an encryption of the sum of numbers. Bob sends to Alice the ciphertext for the sum. Alice decrypts the sum with her secret key and then encrypts the sum with a key known by Bob. Bob receives the sum encrypted with his key and decrypts it successfully.   Question: how can Bob verify that Alice didn't change the sum to a different number before re-encrypting?  Is some sort of zero-knowledge proof helpful?
39627
I read about how is an input message prepared to be hashed by MD4,MD5 or SHA-1:     Step1 Append padding bits      The input message is "padded" (extended) so that its length (in bits)   equals to 448 mod 512. Padding is always performed, even if the length   of the message is already 448 mod 512. Padding is performed as   follows: a single "1" bit is appended to the message, and then "0"   bits are appended so that the length in bits of the padded message   becomes congruent to 448 mod 512. At least one bit and at most 512   bits are appended.       Step2. Append length      A 64-bit representation of the length of the message is appended to   the result of step1. If the length of the message is greater than   2^64, only the low-order 64 bits will be used.  The resulting message   (after padding with bits and with b) has a length that is an exact   multiple of 512 bits. The input message will have a length that is an   exact multiple of 16 (32-bit) words.       ... algorithms steps   I read that hose 2 steps are always the same for input messages for MD4, MD4 and SHA-1. How about  SHA-224 / SHA-256 / SHA-384 / SHA-512? How do they 'prepare' input to compute a hash? The same way maybe?