texts:
What is the expected value of the length of the period of a n-bit linear-feedback shift register with a random tap?
I am asking because I am curious what security issues would appear if the tap would be generated randomly.


texts: On AES, is a true random string enough for a key?

texts: The string (32 ASCII characters) is entered by a human, and considered truly random. Should a key derive from this string, or it is secure to use this string as a key directly? In other words, does deriving a key from this string makes the encryption more secure?


texts: Advantages of group signature schemes without encryption over with encryption

texts:
Many group signature schemes follow sign-encrypt then prove paradigm, where a membership certificate, is encrypted using some public-key encryption scheme. There are some encryption free group signature schemes.

What is the advantage of group signature scheme without encryption over the group signature scheme with encryption?


texts: Would asymmetric cryptography be feasible in World War II?

texts:
Assuming people in the forties would have known asymmetric cryptographic methods like RSA, would they have been able to make sensible use of them?
There were no real electronic computers at the time, but the things achieved in Bletchley Park and elsewhere mean that some processes could have been automatised.


texts:
For quite some time I've been thinking about the idea to construct a hashing algorithm that contains its own checksum value, and thereby can verify itself. With hashing algorithms like SHA1 and MD5 this seems to be difficult although not impossible as explained here. The content that is hashed could never change, but I can think of a few situations where this is absolutely desirable. For example, certificates containing their own thumbprint calculated over all fields. I have tried to design the basics myself once, but that was more ambitious than I had foreseen.

The way I see it there are two approaches:

Narrow down the possible hash values by analyzing the content. Then race for all possibilities to see if the content and the hash match. I have implemented this and although it did work it was everything but usable.
Calculate a hash and adjust the content to match the hash value. For hashing algorithms like MD5 this is near to impossible and any new algorithm would possibly impaired by this.

I'm convinced it is both possible and usable someway, therefore it surprises me how few there is to find on the subject. Are there any case studies or related algorithms to this idea?


texts: Can public key be recovered from ciphertext & encrypted private key?

texts:
I'd like to implement something like a write-once public/private encrypted shared secret (no better quick description for the lack of terminology knowledge). I guess, I'm trying to implement HSM.

The scheme goes as follows:

given a secret (e.g. 512 characters long string)
generate a public & private key pair
encrypt the secret with the public key, for private key to decrypt
encrypt private key, to a hardware token key (OpenPGP smartcard, yubikey, FIDO secure key, TPM etc.) such that only the hardware token can decrypt it.
destroy public key, destroy plain copy of the secret key

The following properties are achieved:

given that public key does not exist, no other encrypted secret can be created for that private key.
both encrypted secret & encrypted private key can be stored externally and transmitted via insecure channels
to unlock the secret, both encrypted secret & encrypted private key must be presented to the hardware module that does on-chip decryption of the private key & decrypts the original secret which is presented back
a single hardware token can unlock unlimited amount of secrets (as they are stored externally)
it's not possible to tell which hardware token can unlock which secrets

Are there fallacies in above argumentation and is it a reasonable scheme?
Can a public key be derived from ciphertext & encrypted secret key?
Can a public key be derived from ciphertext & decrypted private key? (assuming hardware token is flawed and exposed it externally)

Essentially, I'm trying to create a multi-factor scheme to store shared secret which is used for full-disk encryption (LUKS / cryptsetup). With above to access unlocked encrypted disk I'll need to have:

ciphertext
encrypted private key
hardware token to unlock the first two (e.g. smart card)
smart card pin

But I can reuse the smart card for multiple secret/ciphertext/private-key combinations. Or am I unnecessary complicating things, and should simply encrypt the shared secret with a smart card?


texts: RSA: Is possible get p and q from this d and n?


texts: Which functions can be used as Pseudo Random functions? Can block Ciphers be used for this purpose with our own encryption function?

texts: Since the cloud security algorithm I am trying to implement says that for a PRF, any secure encryption algorithm or a keyed hash function can be used. The security parameter I have chosen is 15 bits while AES and SHA use a large key size than this. So which block cipher and encyption function should I use for a PRF?


texts: Why Victor must not know which tunnel Peggy chooses?

texts:
In the classic description of Zero Knowledge Proof of Knowledge, Victor must wait outside the entrance to the cave while Peggy goes to the fork and choose a side. It's only once Peggy has entered a tunnel and is out of view that Victor comes at the fork and shout the side he wants her to come out from.

I am wondering why this setup is necessary for the proof to really be Zero Knowledge.

Let's try a much simpler experiment. Victor and Peggy walk together down the primary tunnel until the fork. Peggy goes alone in one side and come out the other. Victor did not hear the secret to open the door, but he is now convinced that she knows it. Peggy presented a proof of her knowledge without Victor learning anything apart the fact that Peggy has this knowledge.

Why is this simple setup not enough to model ZKPK?

Here are some hypotheses that I'm working with:

The analogy is crafted this way to model the fact that the attacker would always have a probability of $p=0.5$ to guess the correct answer during the interactive proof. If Victor sees Mallory enter the tunnel and not come out the other side he will instantly know that Mallory does not know the secret. To model a setup closer to reality, the indirection is added so that Mallory can fake knowledge half the time.
The analogy is crafted this way to make a point that Victor does not know some part of the mechanism. In our case, the door in fact only opens in one way, and once Peggy is at the door, she only uses her knowledge half the time. Maybe this is to model a mathematical aspect of the proof. I am dissing this one out but I've seen mentioned.
Victor must not be able to convince anyone else that Peggy has the knowledge she claims. This is often presented with the extra story where Victor taped the whole thing while still not being able to convince a third party because he could have conspired with Peggy and staged the experiment.

I feel this third point is the crucial part.

However, it departs from the usual description of simply proving you know something without revealing it.

Hey, I'm Peggy and I can prove to you that I know a secret without telling it to you!
Oh, and by the way, in addition to not knowing the secret you won't be able to even tell anyone else the simple fact that I know the secret, booya.

Is the concealment of this meta information about the relationship between Peggy and the secret what really makes it Zero Knowledge?

Are there practical consequences of having a scheme that discloses it? (If the proof is interactive Victor wouldn't be able to impersonate Peggy anyway, right?).

To make the point more practical and concrete, let's consider the following simple protocols:

Victor sends a plaintext to Peggy and ask her to send it back signed with her secret key. He verifies the result with Peggy's public key. Proof that Peggy has the private key.
Victor encrypts a piece of data with Peggy's public key and asks Peggy to send back the hash of the data. If the hash match, he has a proof that Peggy knows the private key.

Why are these Protocols not Zero Knowledge proof of knowledge? (or are they?)


texts: Encrypting credentials and reusing them securely

texts:
I'm currently building a website where the users would enter their credentials for another web service that I'm going to scrape to get their data.

I want to make sure that when I save their credentials in my database, I'm using the best encryption possible and the best architecture pattern to ensure the highest level of security.

The first idea that I had in mind was to encrypt the data using an RSA pub key (PBKDF2, PKCS1_OAEP, AES 256bit... ???) and then allowing my scrapping script to use the private key to decrypt the credentials and use them.

Could you recommend the right/best encryption to do this?
If my server is hacked, the hacker would have access to both the database and the private key, since it will be kept on my server that runs the scrapping script and hosts the DB. I know that it's a difficult equation to solve. But maybe there is an architecture pattern that helps with this.

I'm coding in python and I believe PyCrypto is the go-to library for encryption. (Sorry I have very little knowledge about cryptography so I might be confusing technologies)

EDIT:

I'm also looking to find out how to design my server(s) to secure all this. I know that if I use RSA, I need to put my private key somewhere where it won't be reachable from internet if my server is compromised, but still the private key needs to be reachable by my scrapping script that needs internet access.

So as you can see i'm a bit lost. I'm ready to use two independant servers but I don't have any idea about the best system design to use here.

Many thanks.


texts: Linkable Ring Signatures on Pairing-Friendly curves

texts:
I'm working on a pairing-friendly (Barreto-Naehrig) elliptic curve. If I understand correctly, one consequence of this is that the Decisional Diffie-Hellman assumption no longer holds, but the Computational Diffie-Hellman assumption still should.

I'd like to be able to construct linkable ring signatures, but all the linkable ring signature schemes I know of depend on DDH for their anonymity proofs, and none of the pairing-based ring signature schemes I know of are linkable.

Are there any linkable ring signature schemes that are usable on pairing-friendly curves?


texts: Is there a construction for a variable length block cipher that uses a fixed length one?

texts:
I'm looking for some way to take a fixed length block cipher (for example AES) and turn it into a variable length one with comparable security. The new length may be bigger or smaller than the underlying block cipher's.

I'm considering going about this with an unbalanced feistel network, but I'm asking if there's an already accepted way to do this.


texts: Diffie Hellman Exponentiation Implementation Problem

texts:
im trying to work on key agreement schemas on embeded systems. for diffie hellman, ive written a 256 bit multiplication, on AVR core it takes about 2 seconds on 1Mhz frequency, lets say my algorithm is weak and it'll work in 1/10 of this time. if we multiply the clock and say were working on 3Ghz PC, we have to exponentiate a 256 bit digit to a 256 bit digit, which means doing the multiplication 1.15e77 ( 2^256) time. with a simple relation, it'll take  e-4*1.15e77 seconds then?? right??? it is really to long to be practical? what am i missing out here?
ty for your answers!!

thanks for your usefull answers so far, but i think my question is a little diffirent!! im not asking a general question, im asking the exact implementation problem, pierre said i would need at most 256 time multiplication, but isn't the public key 256 bits?  then diffie hellman would need 2^256 time multiplication at most? what am i missong here?  thanks for your previous and upcomiong answers!!


texts:
Lets say that I have a server which encrypts information at the server side using ECB mode with the blocksize of 16. If the server appends data that I control with a secret and sends back the ciphertext, it is possible for me to figure out what the secret is, by bruteforcing one character at a time.

Now lets consider a scenario where there is some secret data(say A) being prepended to my data(whose length I'm unaware of). There is also some some other secret data(say B, whose length I'm also unaware of) appended to my data. This is then encrypted and sent back over to me. Is there any way I can figure out what "B" is?


texts: "123456" and "password" as crack standards

texts:
I know that when we encrypt, we use standard encryption technologies and to store data it's often stored as a hash.

By encrypting a common password, for example

  "password"

using MadeUpHashingTechnology it will always equate to

  "awregk;4"

this becomes a standard to use in identifying my hash. Now crackers can look at MadeUpHashingTechnology-Dictionary.com for the most common hashes and see my data more easily.

If I identified n-common or low-strength passwords and simply left them unencrypted (or used a distinctly different encryption) would that help in reducing dictionary attacks? (I'm assuming my password database has been compromised in this scenario)

Would the database need to be compromised for a dictionary attack to be useful?


texts: Why did TLS 1.3 prohibit PGP authentication?

texts:
There is a specification, in Informational(!) RFC 6091, for using PGP keys in TLS authentication, although I don’t think it has ever been implemented outside of GnuTLS (it’s certainly not in OpenSSL).

Yet the TLS 1.3 RFC 8446 §4.4.2 goes as far as to specifically prohibit this obscure extension with a must not. Normally an IETF document would use a should not to recommend against something that’s not fundamentally broken, but still a bad idea in most cases; and RFC 6091 doesn’t seem broken—it just provokes pointless bloat (given the current state of client support and PGP deployment).

What’s the point of such strong language?


texts: How robust is discrete logarithm in $GF(2^n)$?

texts:
"Normal" discrete logarithm based cryptosystems (DSA, Diffie-Hellman, ElGamal) work in the finite field of integers modulo a big prime $p$. However, there exist other finite fields out there, in particular binary fields $GF(2^n)$. There is a specific attack described by Coppersmith for discrete logarithm in a binary field, and it was later on refined into the more general Function Field Sieve by Adleman and Huang. The FFS was used by Joux and Lercier to obtain the current record in $GF(2^n)$ discrete logarithm, where $n = 613$.

What I would like to know is:

How does discrete logarithm in $GF(2^n)$ compares to discrete logarithm modulo a prime $p$ of $n$ bits ? At the time when Coppersmith published his algorithm, it made discrete logarithm in binary fields look easier than its prime $p$ counterpart, but the latter also got improved later on.
Is it important, for discrete logarithm in $GF(2^n)$, whether $n$ is itself prime or not ? The current record is for $GF(2^{613})$, beating the previous record of $GF(2^{607})$, and both 607 and 613 are prime numbers. Would discrete logarithm in $GF(2^{1024})$ be easier than in $GF(2^{1021})$ ?


texts: How would timing attack occur on a particular code but not in another code (because of good coding practice)? Could anyone give an example? I am having trouble figuring out how timing attacks would occur based on the way the code is written.


texts: Textbook-RSA meet-in-the-middle attack against other RSA based schemes?

texts:
A “meet-in-the-middle” (not “man-in-the-middle”!) attack on textbook-RSA was presented to me. The only requirements for it was that the attacker gets the output of RSA and the public key, and that the message be the product of 2 numbers of the same magnitude, which apparently happens with 20% probability. (ie: only eavesdropping).

This attack can reduce the attack of a 64-bit message to O(2^34) instead of O(2^64) for exhaustive search. (ie: almost square root of attack time)

The ISO public key encryption scheme has RSA(pk,x) sent "in the clear" as header. So it seems to me that textbook-RSA can be used to recover x, from which Hash(x) gives the symmetric key…

What am I missing here? Could someone clarify please?

Or maybe I do understand correctly, but that meet-in-the-middle attack on textbook-RSA is not that significant (20% chance of achieving sqrt the time of exhaustive search).

edit: Sorry, I made a mistake: the attack can reduce a O(2^64) exhaustive search into O(2^34) attack which is not almost half the time, but almost square root of the exhaustive search time.

meta: I would like to accept answer but I cannot, neither can I add comments


texts:
I'm reading the paper “Collision-Resistant Hashing? Towards Making UOWHFs Practical” , which compared TCR (Target Collision Resistant) and ACR (Any collision Resistant). It says

  we wish to stress one important practical advantage of TCR over ACR: because $x$ must be specified before $K$ is known, birthday attacks to find collisions are not possible

I understood the definition of the notion of $TCR$, but my question is:

Why is a birthday attack is not possible?

My other questions related to the same paper:
Dependence on Keyed Hash Function • No Birthday Attack to TCR • Weaker Notion of Target Collision Resistance


texts: Is this a correctly formatted PGP session key packet?

texts:
RFC 4880 may be full of information, but it can be incredibly vague at times, so im looking for someone who actually knows the answer to this.

Given this public key:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: BCPG v1.39

mQGiBE5B0h8RBAD533Z5bK1IpBx02QyQL0QoJE4uFRIMGDiwXuwmZzVl+R7Vlurd
GRLsCCbE6vOOh7XQVZGzLEBy9WNzZ9m+EbCfSVAYkjS6FhLws6hG6irrnS+b3JBf
gFJ8vNGF9Z7bhx+7y7NBk0IMyWkGnUkcnav73t5FQUI2faEBN4c/yAGJZwCgjcB7
3akWk9XVWvTCsiMXxpyvkukEALXsvB6cOoFEtQq9cQHjP63fBlvD94dhhMiM0cH6
hW9JotxdK+cxFGG9ZIWgoN2PWbMJka/H4W5EL6tS+YiNAR7I1Ozkt6X16GjnQUzZ
MlSpleK+KiKVN2anRaPEoOIinHrE3ZXd6QlJ/4+OJn4IVWmSEaJpFf4QNgvEu4rh
xinyBAD2RNzREOA+wpnFZ4lDt9NZXmXdxQME/l0J9XcvWhpGsxA/MATQKImy7N49
7GT/M38F+TrpBobag1O3buE99fOLyws4Tbc+sZMdHxoiGZDAIRNQS2rv475E6ktj
7vd5CYvOkA6+8sX1+hPcNlkHtHB1OFkJRsYp6k0zkyC9adjBM7QTYWJjIDxtYWtj
bUBhYWEuY29tPohGBBMRAgAGBQJOQdIfAAoJEDBSJUXPd92GRSQAoItbtbToOg7a
/hcg2sA/aBEQNwuxAKCGR69vmSoCWoBP5waPk0UsjM3BSbjMBE5B0h8QAgCUlP7A
lfO4XuKGVCs4NvyBpd0KA0m0wjndOHRNSIz44x24vLfTO0GrueWjPMqRRLHO8zLJ
S/BXO/BHo6ypjN87Af0VPV1hcq20MEW2iujh3hBwthNwBWhtKdPXOndJGZaB7lsh
LJuWv9z6WyDNXj/SBEiV1gnPm0ELeg8Syhy5pCjMAf9QHehP2eCFqfEwTAnaOlA6
CU+rYHKPZaI9NUwCA7qD2d93/l08/+ZtFvejZW1RWrJ8qfLDRtlPgRzigoF/CXbR
iEYEGBECAAYFAk5B0h8ACgkQMFIlRc933YZRrACfUnWTjHHN+QsEEoJrwRvFmvzj
bR4An24pTpeeN+I6R59O/sdmYsAhjULX
=sStS
-----END PGP PUBLIC KEY BLOCK-----

Can someone verify that the information below is correctly formatted?

Everything here is in hex. I might be missing a few 0s from the front of some values

Tag 1 version(3) + 8 octet keyid + PKA(0x10 = ElGamal): 03f940c4301a67779d10

Session key: b51ba8901efd091d2afcd26b560ea8899d9e2ddbf6aa5c4edea8292704f2fcfc
Checksum: 1092

EME_PKCS1_ENCODE(m): 0002c121793811f4f32f3f739b087f91e77491a0317342c45c6935a80009b51ba8901efd091d2afcd26b560ea8899d9e2ddbf6aa5c4edea8292704f2fcfc1092

k: 5f02cec2fd1f880f390f17dce824c3682015da7ea97c0053cfcdc5097d33fc263e42eeda5c9196a626fa90501a4f7a975061e9f9889f851fcb26e9c24538221e

g^k mod p: 01ff7672e5cc57aaa14b3fda05dee02ecede8a75eecb813060224c390e48f38d3bd41031c9d4659bfaa36246af145930a48d8b5dc5618b4506fb55f6347d5bddffc0

m * y^k mod p: 01ff45f15b84e8e7b95dfef0b52acea10aef4c20b3fc9b8f7c6f2487b2e43b8bfaf5ddebaeddc05643c348eb785559fa7dd74f7542b44ace3746d829fbf1f6392a53

This is a partial block created with only the data from above.

-----BEGIN PGP MESSAGE-----
Version:

wY4D+UDEMBpnd50QAf92cuXMV6qhSz/aBd7gLs7einXuy4EwYCJMOQ5I84071BAx
ydRlm/qjYkavFFkwpI2LXcVhi0UG+1X2NH1b3f/AAf9F8VuE6Oe5Xf7wtSrOoQrv
TCCz/JuPfG8kh7LkO4v69d3rrt3AVkPDSOt4VVn6fddPdUK0Ss43Rtgp+/H2OSpT
=YcRE
-----END PGP MESSAGE-----

is the packet correctly formatted? is the PKCS1 encoded data correct? Simply because pgpdump can read the packet doesnt mean its formatted correctly.

Anyone?


texts: What does the TLS 1.2 client finished message contain?

texts:
I am implementing TLS 1.2 and I'm stuck on the client finished message.

My question is: what is the size and structure of a clients finished message in TLS 1.2 when using the ECDHE_RSA_AES_128_GCM_SHA256 cipher suite.

I searched for this question and someone somewhere stated its size is 48 bytes; more specifically:

12 byte verify data
1 byte handshake type
3 byte verify data length
and 32 byte MAC

Is that really correct?

I mean: according to RFC 5246 finished messages have {verify_data[verify_data_length]} and verify_data = PRF(master_secret, finished_label, hash(handshake_messages). Also, according to RFC 5246 section 5 PRF(secret, label, seed) = P_<hash>(secret, label+seed) and P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed). So, when I compute HMAC using SHA256 for verify_data its size is 32 byte.

As a result, I'm a bit confused in relation to the verify_data size and the finished message structure. Can anyone help me to understand this and/or maybe put me on the right track somehow?


texts: What is the use of a nonce in public-key encryption if it's meant to be shared?

texts:
I'm using PHP. The guys over at paragonie have made encryption easy for the PHP eco-system.

Now, on my computer, Alice, when I encrypt a message using Alice's private key and Bob's public key, I am also given a nonce. Its use? I don't know. I just trust the guys that it's needed and safe.

Thing is, this got me thinking - a nonce, in my book is a protection against forgery, but here I am giving it away. Clearly, if you go to this article: https://paragonie.com/book/pecl-libsodium/read/05-publickey-crypto.md and check the //Bob's computer part, you can see that Bob also needs that nonce Alice generated.

So, what am I missing here?


texts:
I expected to find answers along the lines of quantum-computing insight into attacking AES; however, answers on this question aren't applicable because "Quantum computers give a quadratic speedup on a (sic) general search problems".

Let us suppose the very worst case: P=NP by constructive proof. Therefore, 3-SAT and direct polynomial attacks on AES and all other standard-model symmetric ciphers.

How do we construct something that takes a serious attack to break besides using ECB and sending one block per key? Do quantum-proof symmetric ciphers with properties other than those of the one-time pad actually exist?

I think I can prove that if you use any kind of MAC other than polynomial evaluation MAC (or something else with its characteristic deniability) your cipher must fail.

I can prove that ciphered random data is possible because you can't break ECB over random data, but that proof is useless.

I am aware of the implausibility of ending up in this world of P=NP. I am also aware of this old post describing very good reasons why P=?NP is a poor model for breakability. I am interested in this problem because I am reasonably certain that any solution must use an encryption method that is, of itself, deniable.

The one-time pad has this property; however, I'd rather have an answer that offers something less unwieldy, if possible.


texts: Why Random Secret Necessary Almost in all digital Signature Algorithms

texts:
I've read some introduction documents about digital signatures, and all they said is

Signer calculates a hash of data to be signed.
This hash is encrypted with the private key.
Verifier reads the document and calculates hash again and compares it the received hash which is decrypted with a public key of the signer.

Then I've read the implementations like El-Gamal, DSA, and Schnorr.
They all use an additional random secret variable (referred to as $r$ in three algorithms). What's the purpose of it?


texts: How to apply IV and tag to protect messages encrypted using AES-GCM?

texts:
I'm applying the Arduino Crypto Library for the code fragments.

In the above library, example of encryption and decryption using GCM given as follows:

For encryption:

GCM<AES256> gcm;
gcm.setKey(key, sizeof(key));
gcm.setIV(iv, sizeof(iv));
gcm.addAuthData(adata, sizeof(adata));
gcm.encrypt(ciphertext, plaintext, sizeof(plaintext));
gcm.computeTag(tag, sizeof(tag));

For decryption:

GCM<AES256> gcm;
gcm.setKey(key, sizeof(key));
gcm.setIV(iv, sizeof(iv));
gcm.addAuthData(adata, sizeof(adata));
gcm.decrypt(ciphertext, plaintext, sizeof(plaintext));
if (!gcm.checkTag(tag, sizeof(tag))) {
    // The data was invalid - do not use it.
    ...
}

These are my questions:

Should the IV be unique for each 128 bit text or for each message? How should the next IV be generated? Should we increment the IV by one for each message or for each block of 128 bit?
Does adding the IV in authentication data makes it less secure?
Does sending the computed tag by prepending / appending to the ciphertext, create any vulnerability?
What is the standard way to share the IV & computed tag?


texts:
Is there something like a perfect asymmetric crypto-algo? Is there proof that there must be one or not. From a logical point of view it seems to be possible to design such algorithm if your keysize is high enough.

And please a mathematical solution and not some quantum-cryptography.

Thanks in advance


texts: Strength of block ciphers under attack [by government level attackers]

texts:
So lets say the government has set their top priority to cracking a Veracrypt or Lukes or whatever volume containing highly confidential information.
It uses AES or AES(Twofish). How would they start an attack and how efficient would it be?

Ps: If most block ciphers really are so vulnerable to side channel attack why are most governments still using them for classified information?


texts: Why did they choose $x^4+1$ for the MixColumns step in Rijndael/AES?

texts:
In The Design of Rijndael page 39, It describe the design criteria for MixColumns step

Dimensions. The transformation is a bricklayer transformation operatingon 4-byte columns.
Linearity. The transformation is preferably linear over GF(2).
LisDiffusion. The transformation has to have relevant diffusion power.
Performance on 8-bit processors. The performance of the transformationon 8-bit processors has to be high.

However, it does not said why choose modulo $x^4+1$ operation in this step. I guess it is becasue it is the simplist polynomial operation otehr than modulo $x^4$, which will cause multiple zeros. I will glad if anyone tell me my guess is wrong.


texts:
Say I have access to a system A that is limited to performing (EC)DH, followed by key derivation to produce a secret key. This secret key is later used to provide integrity protection.

There is a party B want to use this system to create a signature over some data. This signature can then be used to prove to a party C that A created the signature over the data. Party C of  has access to the trusted public key belonging to the key pair of A.

Rules:

there is one static public / private key pair for A
no other operations are allowed on the private key of A
party B need to supply a public key to A to perform (EC)DH, but this may in fact be any data
the public key offered by B to system A does get validated according to the (EC)DH scheme used
any signature scheme is acceptable, as long as the signature can be verified by party C
the secret key is generated using a KDF over the generated shared secret

Is it possible to generate a signature over data with this kind of system? If not, can you offer some kind of prove that it is not possible? If so, what would such a signature scheme look like?

If it is not possible, what if the key derivation part was left out and the shared secret could be used for any operation?


texts: Generalizing a CBC-MAC collision with a common final message block

texts:
I found this question from a textbook but I don't really understand what it is asking:

Suppose $c$ is $1$ block long, $a$ and $b$ are strings that are a multiple of the block length, and $\text{CBC-MAC}(a||c) = \text{CBC-MAC}(b||c)$. An ideal block cipher is used in $\text{CBC-MAC}$.

Explain for which most general class of messages $d$,
$\text{CBC-MAC}(a||d) = \text{CBC-MAC}(b||d)$.

I don't understand how can $CBC-MAC(a||c) = CBC-MAC(b||c)$ unless $a = b$?


texts: Using NewHope key exchange between browser and BouncyCastle implementation

texts:
I have been looking around with some new Post-Quantum secure key exchange methods, such as McEliece, NTRU and SIDH, but none of these seem to be working nicely between the browser and the BouncyCastle implementation.
McEliece falls off very fast since the keys are exorbitantly large; not necessarily an issue, but not convenient.

My latest iteration is using the NewHope key exchange scheme, which looks to be simple in use and I can't see why it is not working. I found this AMCL crypto library which implement it as specced (as far as I can see), but generating a shared key is not working.

My javascript implentation is as follows (looking at their test code):

let ctx = new CTX();
let RAW=[];
let crng=new ctx.RAND(); crng.clean();
for (let i=0;i<100;i++) RAW[i]=i+2;
crng.seed(100,RAW);
let SB=[];
let UC=[];
let KEYB=[];

function nh_ss() {
    SB = hexStringToByte(document.getElementById("nh_pk").value);
    ctx.NHS.CLIENT(crng,SB,UC,KEYB);
    document.getElementById("nh_uc").innerHTML = byteToHexString(UC);
    document.getElementById("nh_result").innerHTML = byteToHexString(KEYB);
}

Here the servers' public key is input into the "nh_pk" field and converted using convenience methods:

function byteToHexString(uint8arr) {
    let hexStr = '';
    for (let i = 0; i < uint8arr.length; i++) {
        let hex = (uint8arr[i] & 0xff).toString(16);
        hex = (hex.length === 1) ? '0' + hex : hex;
        hexStr += hex;
    }
    return hexStr.toUpperCase();
}

function hexStringToByte(str) {
    let a = [];
    for (let i = 0, len = str.length; i < len; i+=2) {
        a.push(parseInt(str.substr(i,2),16));
    }
    return new Uint8Array(a);
}

The BouncyCastle implementation is simple as well, following the request-response flow as specced:

NHKeyPairGenerator keyPairGenerator = new NHKeyPairGenerator();
keyPairGenerator.init(new  KeyGenerationParameters(new SecureRandom(), 1024));
AsymmetricCipherKeyPair keyPair = keyPairGenerator.generateKeyPair();
NHPublicKeyParameters publicKey = (NHPublicKeyParameters) keyPair.getPublic();

System.out.println("public key:\n" + Util.bytes2hex(publicKey.getPubData()));
System.out.println("Enter response value: ");
Scanner scanner = new Scanner(System.in);
String response = scanner.nextLine();

byte[] bytes = Util.hex2bytes(response);
NHPublicKeyParameters keyParameters = new NHPublicKeyParameters(bytes);

NHAgreement agreement = new NHAgreement();
agreement.init(keyPair.getPrivate());
byte[] agreementValue = agreement.calculateAgreement(keyParameters);
System.out.println("agreement value:n\n" + Util.bytes2hex(agreementValue));

But the shared values are not corresponding at all, and I'm not following what is going wrong.

The same goes for the other implementations, though the test code for the client and the test application is very messy, they should work.


texts: How to extract MAC and AES keys using x9.63 based kdf

texts:
For trying ECIES, I need to derive keys for MAC and AES from the shared secret using ANSI x9.63 based KDF. The information on key derivation I got it from Section 3.6.1 of http://www.secg.org/sec1-v2.pdf.

What is the standard procedure to extract/separate the keys for MAC and AES from the Key derived using KDF?


texts: Trapdoors for Lattices: CCA-secure encryption

texts:
In Trapdoors for Lattices:Simpler, Tighter, Faster, Smaller, Micciancio and Peikert proposed a CCA-secure encryption.

However, I am confused about the step in decryption algorithm (p.36 Lemma 6.2.).

That is, $\mathbf{v}^t \begin{bmatrix} R \\I \end{bmatrix} = 2(\mathbf{s}^th(u)\mathbf{G}$ mod $q$) + encode(m) mod $2q$.

And why $2(\mathbf{s}^th(u)\mathbf{G}$ mod $q) = 0$ mod $2q$, such that decode($\mathbf{v}^t \begin{bmatrix} R \\I \end{bmatrix})$ = decode(encode(m)).


texts: Why does a Hashing Function produce good Random Numbers if Input is random?

texts:
I've heard about using a hash approach to create random numbers based on two independent entropy sources A, B:

$h_{i} = H(a_i+b_i)$

$H$ could be for instance SHA-1, or SHA-256.

My questions are:

1)

I read that hashing an input of s Bits to an output of n bits will reduce entropy because of truncation. The accepted answer in

How much entropy is lost via hashing when you add known or low entropy data?

sounds totally reasonable for me. But what does it mean in terms of quality of randomness? When an input of, lets say, 1024 bits is hashed to 256 bits, of course entropy gets lost. But can't I say, that the "remaining" 256 bits are still good random numbers and not comromised by the truncation of length? Isn't it just the rate of available random bits which is reduced, not the quality of randomness?

2)

Why is a hash function $y=f(x)$ like SHA-1 a random oracle at all?
So far I know, it means, that the set of arguments x is mapped to a set of results y, distributed equally over $2^{256}$ values in the case of SHA-256. Why is this the case? Is there a rigorous proof for that or is it only a working assumption? It would mean for my feeled understanding:

An s-bit value $x_1$ feed into Hash results in n bits $y_1$,
An s-bit value $x_2$ feed into Hash results in n bits $y_2$,
When $x_2$ differs from $x_1$ in only one bit position, all bits of $y_1$ are totally "uncorrelated" to the bits of $y_2$, regardlesss of the changed bit position.

Is that right?

Although I feel that this should be the case for a good hash of course, I wonder if the goal is only approximately achieved or really accurate?
(Even the word "uncorrelated" is difficult to grasp for me, since, in fact,  there is some kind of correlation over the hash-algorithm)


texts: Why was Vaudenay's original padding oracle attack not exploitable on TLS 1.0?

texts:
Reading Password Interception in a SSL/TLS Channel that was released in 2003:

  At Eurocrypt’02, Vaudenay presented vulnerabilities in padding schemes used for block ciphers in CBC mode. He used a side channel, namely error information in the padding verification. This attack was not possible against SSL/TLS due to both unavailability of the side channel (errors are encrypted) and premature abortion of the session in case of errors.

In Vaudenay's 2002 paper:

  TLS v1.0 (also) provides an optional MAC which failed to thwart the attack: when the server figures out that the MAC is wrong, it yields the bad_record_mac error. However, the message padding is performed after the MAC algorithm, so the MAC does not preclude our attack since it cannot be checked before the padding in the decryption.

it continues:

  The reason why the attack is not so practical is because the padding format error (the decryption_failed error) is a fatal alert and the session must abort.

Now, how bad is this? Bad padding leads the section to break OK, but 1 out of 256 times the padding will be correct and one byte of plaintext will be recovered. This should be enough, and in the same manner of BEAST-style attacks more bytes could be recovered by shifting the payload so that the byte of a cookie we want to recover is always the LSB. I fail to understand why these people thought this was not exploitable.

To add to this, it looks like Canvel, Vaudenay and others actually knew about this but didn't know this was fully exploitable:

  As pointed out in [17], the attack could have still worked in order to decrypt only the rightmost byte with a probability of success of 2−8. It can also be adapted in order to test if x ends with a given pattern.

Although they later add:

  This does not work either against TLS for another reason: because error messages are not available to the adversary (they are indeed encrypted and indistinguishable).

How is an error, even encrypted, indistinguishable? I'm guessing it would be a short message compared to a long normal response.


texts: Is there any proof for ECDSA signature algorithm?

texts: Related: Is there an interactive version of ECDSA signature protocol like the Schnorr identification protocol?


texts: Is it safe to reuse the same nonce for decryption an indefinite amount of times in this context?

texts:
I'm creating a password management application and I'm considering using the following procedure to keep passwords safe:

Asking the user for raw_password, for example "MyLongMasterKeyPassword"
Generating master_key from raw_password with Scrypt and a random salt
Storing the salt (kept public)
Asking for raw_message (the password to store)
Generating cipher using AEAD-ChaCha20Poly1305IETF and generating a random nonce, and then asking for AD(Additional authentication)
Storing the nonce
Encrypting raw_message with cipher, nonce, and AD, then using the nonce once for encryption, that returning cipher_text
Storing the cipher_text
Decrypting cipher_text with stored salt and nonce, then asking for AD and raw_password to regenerate the master_key with the stored salt, and then generating a cipher with the master_key and stored nonce, which returns the decrypted_message (a password, probably)

Now, the question is, is this procedure safe? Specifically, is it safe to re-use the same nonce for decryption an indefinite amount of times, if you only use it once for encryption?


texts:
I have all of the Shamir's secret shares required to Lagrange-interpolate f(0), which represents an ECDSA private key. The field of this object is secp256k1, which has associated prime number p=115792089237316195423570985008687907853269984665640564039457584007908834671663.

The Lagrange interpolation produces a negative f(0), but because curves over secp256k1 can have exactly 0 or exactly 2 y-coordinates at any x, I'm assuming I can use the absolute value of f(0).

My other understanding is that since we're working over the finite field Zp, S = f(0) (mod p). Where I'm held up is how to turn this 77-byte number (S) into the ECDSA private key.

I've tried reconstructing a wallet using S in hexadecimal as the private key, as well as the sha256 of S, but I don't believe either of those methods are correct.

Are my previous assumptions correct, and if so, how should I go from S to the ECDSA private key?


texts: Use large key size for RC4 to avoid RC4 bias

texts:
I saw a question on StackOverflow where RC4 was initialized by a 1024 bit key (with 2048 the maximum key size, if I'm not mistaken).

Will such a large key size possibly solve any of the bias of the initial bits of the key stream produced by RC4? Does it increase security any other way - other than brute force?

Is there any reason for keys larger than 256 bits for a combined key + IV?


texts:
The specification for OMAC has the following to say about OMAC2:

For OMAC2, we adopted u−1 instead of u2 as Cst2. It requires one right shift to compute L· u−1 instead of one left shift to compute (L· u)· u. This would allow to compute both L · u and L · u−1 from L simultaneously if both left shift and right shift are available (for example, the underlying block cipher uses both shifts).

This seems to imply that the only (?) purpose of OMAC2 is to be more efficient to calculate if you're operating on hardware that implements both a left and a right shift? (How luxurious! Oh wait, what hardware doesn't do that?)


texts:
I was wondering if it was possible to recover an AES-128 blockcipher key, knowing that there is no substitution box (it can be seen as the identity mapping). I thought it would be feasible.

I implemented this AES version and I tried, first, a DFA.
Because MixColumn and ShiftRow are both linear operations we can inject manually a fault on a given byte at the 9th round, before the mix column. Then I used phoenixAES to compute the last round Key, but it is not working (I have modified the Sbox in the phoenixAES programm).

The only other solution I see now is to express each round key as a function of the master key (the key schedule is now linear) and to use the fact that $$AES(P)=AP+K$$ where K depends only on the round keys (we can compute its exact expression) in order to solve a linear system, but it seems really grueling.

Do you know if the Rijndael box is needed to perform a DFA on AES (the error diffusion should be the same with every box ?!)

Do you see an other way to solve this problem ?


texts:
When using AES in CBC mode, padding is required when the last plaintext block has not the length required by the cipher. Let's say $k$ mode bytes would be required to fill the block. My idea was to pad the last block with $k-1$ random bytes followed by one byte that corresponds to the integer value of $k$ (or $k-1$). That is, it tells how much padding was added. When decrypting, the previous decrypted block is held back, until it is clear that it was not the second to last block. If it was, the padding is removed accordingly and the full plain text is obtained.
Is this a secure way to pad a message?
More generally, are there problems that may arise from this method of padding, or can an incorrect padding scheme compromise the cipher?


texts: How does one calculate a primitive root for Diffie-Hellman?

texts:
In the Diffie-Hellman key exchange, one of the steps involves calculating a primitive root of a prime number $p$. How would one go about doing so, considering that $p$ could be very large?

Is there some sort of algorithm or equation?


texts: Secret Sharing: Is this simplification secure?

texts:
I am a mathematician with no background in crypto or security. For work, I had to read up Chap.13 "Secret Sharing Schemes" in Stinson's Cryptography (3rd ed). My question is about a simplification of the so-called Monotone Circuit Construction.

In Sect. 13.2 Stinson discusses the case that you have $w$ participants $\mathcal{P} = \{ P_1, \ldots, P_w \}$ and you want to realize the access structure $\Gamma \subseteq 2^{\mathcal{P}}$, which is just an arbitrary set of subsets of $\mathcal{P}$. This means, exactly the subsets in $\Gamma$ should get access to the secret and no other group.

The method he presents was invented by Benaloh & Leichter (CRYPTO '88) and is called (by Stinson) the Monotone Circuit Construction. The idea is simple: You build a monotone Boolean circuit that "recognizes" $\Gamma$ and then compute the shares based on the wiring of the circuit (see Algorithm 13.1).

All this is fine, but it seems a bit overblown. Why not do the following? For each group of $\Gamma$ with $t$ participants you just "split" the secret number randomly among them (meaning, you use a $(t,t)$-Threshold Scheme) -- and you're done. This even should be a special case of the Monotone Circuit Construction.

I have two questions about this:

Is the above suggestion secure?
What's the advantage of the more general approach as presented by Stinson?


texts: Does repeated xoring of the (same) key K lower the entropy of K?

texts:
If a symmetric encryption key $K$ has been generated by some recommended (NIST for example) RBG then we should have a key with high entropy.

But if we xor other bit-strings (e.g. IVs, other keys, etc.) to $K$, how does this affect the level of the entropy of the resulting bit-string?

Specifically, how is the level of entropy affected if we apply:

$K \oplus K^*$, where $K^*$ has the same/similar level of entropy as $K$.
$K \oplus IV$, where $IV$ has a much lower entropy than $K$.
$K \oplus C$, where $C$ is some ciphertext output that is (repeatedly) fed back into the cipher to begin a new round.

In short, I am interested in the effects of entropy levels when a 'strong entropy' bit string is xored with a 'weak entropy' bit string or another 'strong entropy' bit string.

Related to Q3, I wonder how many times an output can be xored with the same key before entropy is lowered (assuming that happens at all). We assume the output $C$ is different each time.

It seems this cannot happen because the output $C$ of a cipher should necessarily be unpredictable, but that is on the assumption that xoring two high entropy bit strings will always retain a high entropy.

Is there a simple mathematical way to show entropy is retained or lost when two bit strings are xored?


texts: How can a client privately query a subset of a database?

texts:
I am trying to build a solution for the following problem and I think it is relevant to crypto:

Party A has a set of indexes M, such as a group of people's ID; Party B has information of a larger group of people, and we name the set of this group as N. Let's assume M is a subset of N. Party B agrees to provide information of people whoever requested by A for a business purpose. Although party A wants to have all the information of M from B, it does not want to reveal any ID in M to Party B during the process.

Does anyone know if this is possible?

Thanks.


texts:
For the following explanation of RC4:

  It is a variable key-size stream cipher with byte-oriented operations.  The algorithm is based on the use of a random permutation.  Analysis shows that the period of the cipher is overwhelmingly likely to be greater than $10^{100}$."

What does it mean by the period of the cipher and greater than $10^{100}$?


texts: AES-256 CTR with ESSIV, is this correct?

texts:
I am having some problems encrypting disk using AES-256 in CTR mode, with ESSIV iv generation (I am aware of couple of flaws, although this mode is enough for now). What I have here is:

S = SHA256(K), result 32 bytes
K = original key, 32 bytes
SN = sector number, 16 bytes
E = AES-256 CTR
IV2 = generated iv, 16 bytes

What I am doing with it:

IV2 = E(data=SN, key=S, iv=SN)
decrypted_data = E(data=encrypted_data, key=K, iv=IV2)

In couple of sources (e.g. here: https://is.muni.cz/th/vesfr/final.pdf) I got that for ESSIV generation I should use the exact same block cipher as for main de/encryption. However, I am getting wrong results. Is this the correct approach?

Thanks.


texts: Salts, how does the script know what the salt is?

texts:
I am new to PHP programming and trying to grasp the idea of hashing and encryption for protecting passwords, credit card details and such. I've done a lot of reading about MD5 which I think I understand the basics of now. I've seen places recommending that I use SHA2, which I don't understand how to implement.

Back to my question. I can understand how a script can tell if a password is correct or not by hashing the password and comparing the value against the hashed one in the database. My problem occurs when trying to understand salts. If I have a dynamic salt such as the date (yes, I have heard its a bad one to use), how does the script know that a password is correct because the salt will be different for the entered password and the one stored in the database.

For example:
Say the original password was created on the 21/02/2011:

unhashed with salt:

mypassword210211

hashed with salt:

cbc0a790b2f28fc72ca43eb749028b9f

Then if I check my password today:

unhashed with salt:

mypassword30012012

hashed with salt:

e4af7ca7e263750a15be642d903c9ac9

They're completely different, so how does the script know that they are the same? Do I have to store the salt used on the specified password in the database so it knows what to use next time?

I'm rather confused and its highly likely that I am not understanding the whole hashing process properly. I've done my research, but whether I have done correctly or not I don't know.


texts: How hard is a known prefix hash preimage attack on SHA-2?

texts:
Suppose the attacker knows $X, Z$ such that

$H(X || Y) = Z$

If bit-length(Y) < 60 then a brute force attack is possible.

What if bit-length(Z) = 256  (such as in SHA-256), bit-length(X) = 128, or bit-length(Y) = 256? Are there any published paper with results/experiments with SHA-256/512 in full or reduced rounds? Are there specific known attack techniques?


texts: Why does a one-time-pad key have to be at least as long as a message?

texts: I am studying one time pad and find it hard to understand. What happens if the key is one bit or 100 bits shorter than the message?


texts: 7-Zip Encryption: Practical Effect of Lacking Salt

texts:
A previous discussion on Cryptography StackExchange leads me to understand that 7-Zip does not use salt to derive an encryption key from password to use its AES-256 encryption; that this is a potentially severe shortcoming; and that its impact is to make it relatively easy to crack multiple .7z files.
My question is, what does this mean in practice? Possible inferences or points of confusion:
(1) Virtually all other notable AES-256 file encryption tools (e.g., AES Crypt, Gpg4win, Cryptomator) do use salt; therefore they are significantly more secure than 7-Zip.
(2) The absence of salt doesn't have any practical effect on brute force password cracking methods, else Elcomsoft would not say that .7z is still harder to crack than RAR5.
(3) The absence of salt is a severe shortcoming only where the cracker seeks access to multiple .7z files. But why would that make a difference? If all those files use the same password, then yes, brute forcing one will open them all. If they use different passwords, the absence of salt would presumably make no difference.
(4) The absence of salt in 7-Zip is moot if I use some other AES-256 tool with salt to create a .7z file.


texts:
I am reading the paper - "RAPPOR: Randomized Aggregatable Privacy-Preserving Ordinal Response".

I don't understand how the averaging attack works.

I searched for "average attack" but couldn't find a related explanation.

Can someone explain it to me?

Thank you!


texts: Is there any valuable Cryptography certification for working in the field?

texts:
I'm an amateur math/crypto/CS passionate, but I find myself without any degree or certification that gives credit to my skill-set, specially on math and crypto. Currently I'm designing cryptosystem on non-commutative cryptography, trying to cryptoanalise my own trapdoor functions, measuring security parameters, testing new platform groups, etc. Eventually I write down all my investigations and write a paper if it's something to take into consideration.

I think that a professional on the field would classify my work as pure recreational, but I'd like to dedicate my working life as someone who uses math/crypto at computer security level.

Is there any degree/title/certification that is respectable and valuable enough? By "valuable enough" I mean that does not just cover the basics and that must be updated to nowadays times.


texts:
I´m trying to follow one of the very detailed RSA Proofs given by di-mgt: "RSA theory", but unfortunately I stuck at the beginning of solution (chapter 3).

I don´t understand where the second part of (8) is coming from:

$RsaPrivate(RsaPublic(m))\ =\ (m^e\ mod\ n)^d\ mod\ n\ =\ m^{ed}\ mod\ n$

How is it reduced? Where can I find this rule?


texts: DES decryption of the homomorphic encryption ciphertext

texts:
I implemented an application using partial homomorphic encryption for outsourced computations. To get an efficient bandwidth, I am thinking to apply (DES) symmetric algorithm to encrypt the message instead of HE before uploading it to the cloud.
Can I perform DES decryption operations (permutation and S-boxes) on homomorphic encryption ciphertext?
$
\begin{align}
&C = \operatorname{DES}(m)\\
&C'= \operatorname{FHE}(C) = \operatorname{FHE}(\operatorname{DES}(m)) \\
&\operatorname{DES}^{-1} (C' )= \operatorname{DES}^{-1} (\operatorname{FHE}(C))= \operatorname{DES}^{-1} (\operatorname{FHE}(\operatorname{DES}(m)))= \operatorname{FHE}(m)
\end{align}
$


texts: Understanding the q-SDH Problem (on elliptic curves)

texts:
I have some troubles in understanding the q-SDH problem. The discrete logarithm problem states the following.

Given a point P of order on an elliptic curve and a point Q on the same curve. It is hard to find a such that $0 \leq a \leq p-1 $ and $Q = aP$.

The q-SDH problem states the following:

Let $g_1$ be a generator of the elliptic curve. Given $\beta \in \mathbb{Z}_q^*$ and q+1 tuple $(g_1, \beta g_1, \beta^2g_1, ..., \beta^qg_1)$ it is hard to find the SDH tuple $(x, \frac{1}{\beta+x}g_1 ) $

I do not understand why we have to find $\frac{1}{\beta+x}g_1$. Why is this hard? What is the underlying problem? Is the discrete log problem somewhere hidden? Why do we need x?


texts: How is Blakley's Secret Sharing Scheme perfect?

texts:
Currently, I am trying to understand Blakley's secret sharing scheme. However, there seem to be multiple descriptions of it, which are very different from another, but everyone states that the scheme would be perfectly secure.

From my understanding it works like this:

a point $S$ in $t$-dimensional space is created with one coordinate being secret and the others randomly selected
$n$ hyperplanes through the point $S$ are created and distributed
to reconstruct the secret, $t$ hyperplanes are required, which will intersect at the point $S$.

However, from my understanding, if someone would possess one or more hyperplanes, they would know that $S$ lies somewhere on that hyperplane (or the intersection of multiple hyperplanes)

So my question is;

how is Blakley's scheme considered perfectly secure when an insider knows that the secret lies on his plane?


texts:
I have implemented a ruby code where i generate private and public keys as below.

However, I read few articles [1] on DSA and why it should not be used. I'm not good at cryptography. But still wanted to know whether my implementation is vulnerable to recover public/private key?

$group = ECDSA::Group::Secp256k1
$private_key = 1 + SecureRandom.random_number($group.order - 1)
$public_key = $group.generator.multiply_by_scalar($private_key)


texts: How to deal with collisions in Bitcoin addresses?

texts:
When creating a Bitcoin account, you need to issue a couple of private/public ECDSA keys. Then, you derive your account address by taking a 160-bit hash (through SHA-256 and RIPEMD) of the public key and use a custom Base 58 algorithm to convert it to alphanumeric values (see the picture below, I took it from this page).

My question is that collisions might happen (not necessarily malicious ones, but incidental ones). I would like to know whether there is a specific mechanism in the Bitcoin protocol to sort out these collisions and be ensured that the payment is going to the right place.

In fact, I tried to look through the protocol details but could not find anything dealing with this problem. The only reference I found is on the Bitcoin-wiki and it states that:

  Collisions (lack thereof)

  Since Bitcoin addresses are basically random numbers, it is possible, although extremely unlikely, for two people to independently generate the same address. This is called a collision. If this happens, then both the original owner of the address and the colliding owner could spend money sent to that address. It would not be possible for the colliding person to spend the original owner's entire wallet (or vice versa). If you were to intentionally try to make a collision, it would currently take 2^107 times longer to generate a colliding Bitcoin address than to generate a block. As long as the signing and hashing algorithms remain cryptographically strong, it will likely always be more profitable to collect generations and transaction fees than to try to create collisions.

  It is more likely that the Earth will be destroyed in the next 5 seconds, than that a collision would occur sometime in the next millennium.

I found this explanation extremely unsatisfactory. If any of you have a better explanation than that, or know about a prevention mechanism that has been planted into the Bitcoin protocol, I would be delighted to read about it.


texts: How to Update Non-Membership Witness upon deletion in RSA Dynamic Universal Accumulator

texts:
The Universal Accumulator paper mentions the following for updating non-membership witness upon member deletion.

Choose $r$ such that $a\hat x − rx ∈ Z$$2^l$

What is Z$2^l$ and how can we efficiently evaluate $r$?
I suppose we need to brute force search by guessing values of r, is there any room for optimization here? Perhaps by making an educated guess about the value of r.
Update:
Can it be that $a\hat x − rx$ can be construed as $a\hat x$ $mod x$? If yes, then we can find
$\hat a = a\hat x$ $modx$
And,
$r = (a\hat x - \hat a)/x$
Am I right in assuming this?


texts: Does the elliptic curve (EC) cryptosystem outperform RSA and DL cryptosystems?

texts:
Throughout the literature, it is stated that EC cryptosystems outperform RSA and Discrete logarithm cryptosystems, but I cannot understand how ECC would be more efficient than RSA and DL in terms of computation and storage.

Is there any pragmatic performance analysis comparing these cryptosystems so that I can understand?


texts: How do disk encryption programs solve the "IV problem"?

texts: I was reading a paper on the "elephant diffuser" used in BitLocker and it got me wondering how other systems (e.g. TrueCrypt before it shutdown) solved the problem the elephant diffuser was meant to solve; namely that there isn't enough space on a disk block to store an IV.  Where is the IV stored in other systems or do they have alternative solutions?


texts: How are the attributes of a user authenticated in attribute-based encryption?

texts:
It seems that the papers I am reading do not talk much about this point. That is how the attributes of a user are authenticated in ABE system.

To my understanding, there is an attribute authority (AA) who authenticates the attribute of a user and there is a PKG who generates the private key based on the authenticated attributes.
So, are AA and PKG two separated parties or a single party?

Also, I am reading some papers about the trust issue in AA and PKG. To my understanding, we can only reduce the trust in PKG but not in AA. Because, the AA can authenticate anyone (including itself) as an authenticated user possessing some attributes. Then after going through the normal process, that user can always obtain the valid private key. Thus, it seems that we still requires a fully trusted AA.  I am not sure whether my understanding is right or not. Any comments on this point would be helpful.

Thanks.


texts: Why does CBC-MAC need prefix-free inputs to be a good PRF?

texts:
In the FFX spec, there is a note about using CBC-MAC as the round function.

  Security notes. The round function F is constructed in such a way that the set of inputs on
  which the CBC-MAC is invoked is preﬁx-free. (A set of strings is preﬁx-free if for any distinct x, y
  in the set, x is not a preﬁx of y.) The CBC-MAC is known to be a good PRF when it is invoked
  on a set of preﬁx-free inputs, assuming AES is a good PRP [23].

Why is it important that the input be prefix-free? The citation is for Erez Petrank and Charles Rackoff, ‘CBC MAC for Real-Time Data Sources’, Journal of Cryptology 13(3), 2000, pp. 315–338 (paywall-free, tech report, preprint).


texts: Are zero-knowledge proofs quantum-resistant?


texts: Has a Two Key TDES encryption ever been successfully attacked?

texts: Is there any known instance of a Two Key TDES ever being successfully attacked (in real life), when the key is used to encrypt less than $2^{20}$ words?


texts:
So let's say you're trying to do SHA3-224.

If you're on a 64-bit machine you'd presumably use KECCAK-$f$[1600]. In-so-far as I understand it'd have the following parameters:

Rate: 448 (2*224)
Capacity: 1152 (1600 - rate)
Rounds: 24
Rotation constants: described in https://keccak.team/keccak_specs_summary.html  (last table)

With a 32-bit machine you'd presumably be using KECCAK-$f$[800] with the following parameters (last table):

Rate: 448 (2*224)
Capacity: 352 (800 - rate)
Rounds: 22 ($12 + 2*\log_2(800/25)$)

Assuming that that's all correct then what I'm wondering about is how the rotation constants would work.

https://keccak.team/files/Keccak-reference-3.0.pdf#page=21 gives a formula for determining the rotation constants: $(t+1)(t+2)/2$ and https://keccak.team/files/Keccak-reference-3.0.pdf#page=22 shows a table with the results of the formula. To get the rotation constants at https://keccak.team/keccak_specs_summary.html you take the lower lower six bits of each of those numbers (eg. $x \land 0x3F$ or $x \mod 64$).

For KECCAK-$f$[800] would you take the lower five bits (eg. $x \land 0x1F$ or $x \mod 32$) of each of those numbers?

A lot of the 32-bit SHA3 implementations I've seen seem to do KECCAK-$f$[1600] and just simulate 64-bit numbers with 2x 32-bit numbers.


texts:
The Luby-Rackoff theorem states that if a round function is a secure pseudorandom function (PRF)
then 3 rounds are sufficient to make the block cipher a pseudorandom permutation (PRP).

PRPs are invertible whereas PRFs are not. How come 3 rounds of a PRF
will make an invertible block cipher out of a non-invertible function?


texts: Can $AES_{k1}(m)$ be equal to $AES_{k2}(m)$?

texts:
Context:

We have a generic bloc cipher composed of an encryption function $E_k$ and a decryption function $D_k$ operating on blocs of $n$ bits.

For a key $k$ fixed, we can see $E_k$ as a pseudo-random permutation from $\{0,1\}^n$ to $\{0,1\}^n$ (I am wrong ?). $D_k$ is the inverse permutation.

If we have a plain/ciphertext pair $(m, c)$, a common bruteforce attack consists in enumerating all possibles $k$ and testing if $E_{k}(m) = c$.

Question

1) Considering that $E_k$ is a random permutation, can we have two keys, $k1$ and $k2$ such as $E_{k1}(m) = E_{k2}(m) = c$ ?

2) If the answer is yes (and I think it is), how many $(c,m)$ do we need to uniquely determine the right key ?

3) And do we have the same problem for common bloc ciphers like AES or DES (i.e getting more than one $(c,m)$ to uniquely determine the right key) ?

Thanks for your answers.


texts: Is there any serious discussion about using blinding intermediaries in digital currency scenarios?

texts:
A digital currency system like Lucre (OpenTransaction) creates a coin by a mint blind signing the output of a hash function, which the payer then unblinds and pairs with the input to the has function.

In this way, the coins themselves cannot be used to identify the payer; however, the payee and the mint are free to correlate their information about the payer's identity through side channel information, such as IP address and rebuild the payer's identity.  There are afaik two orthogonal partial solutions to this problem :

The payer may reduce side channel information, say by using Tor, not giving one party a real name, etc.  This potentially offers good security, but imposes a great burden upon the payer.
The protocol and payer may instead insist upon an intermediary between the payee and the mint, i.e. the payer blinds the coin using his intermediary's daily public key, the payee blinds the coin using the mint's key, and the intermediary unblinds the coin before delivering it to the mint.  This prevents the mint form ever reestablishing that the payer held that particular coin.

I could imagine a few uses for #2 but I haven't seen much discussion about it.  Is it interesting?


texts: Is it possible to tweak AES-GCM so that it is satisfactory for whole-disk encryption (like XTS mode)?

texts:
Is it possible to leverage a preexisting implementation of AES-GCM to provide the key security benefits essential for full-disk encryption (similar to AES-XTS)?

GCM is a popular encryption mode supported by several libraries and with fast implementations in hardware, and on its own GCM has nice properties including parallelism. Because of GCM's built-in authentication functionality and due to its performance, it is beneficial to consider that as a starting point; a hardware implementation may implement AES-GCM as a self-contained performance routine.

But on the other hand, a critical requirement of GCM (essential to its security) is that it must have unique random IVs, just like CCM. So if the IV that is chosen is derived from the sector or block offset (even if there's an intermediate hash), the very fact that on a disk it's common to write and overwrite data in place (coupled with GCM and CCM behaving nearly like stream ciphers) makes it potentially dangerous to derive the IV in that deterministic way. But just like many encryption modes are based upon compositions of cryptographic primitives, I'm wondering if it's possible to start with GCM (and its AEAD property) and build upon that to also attain the secure capability of writing to disk at sector offsets.


texts: Is it possible to have interactive decryption?

texts:
Is it possible to have an encryption and decryption scheme so that decryption is a 2-party process?

For instance, Alice sends an encrypted message to Bob along with the key for that message. Bob, by himself, cannot feasibly decrypt this message. However, with some interactive help from Alice, he can decrypt it. If Bob manages to lose the plaintext after this process, the information gained during the decryption process cannot help him decrypt it again. He must ask Alice for help again.

I could see this being useful in access-control systems or DRM.


texts: Do any stream ciphers with aperiodic keystreams exist?

texts:
Exactly what it says on the tin. I can imagine constructing such keystreams from:

The binary expansions of irrational numbers
Chaotic systems like the logistic map or the Lorenz attractor.
The bitmap representations of images.
Extracting the y-coordinate from equations such as $sin(x)$ or $e^x \mod 1$ every n increments.


texts: Significance of Gram-Schmidt coefficients in LLL algorithm

texts:
Let $\{ {\bf v}_1,{\bf v}_2 \}$ be two linearly independent vectors. An orthogonal base $\{{\bf u}_1,{\bf u}_2 \}$ of the vector space $\mathrm{span}\{ {\bf v}_1,{\bf v}_2 \}$ can be computed using Gram-Schmidt Orthogonalization process (GSO) which is summarized by the formulas
$${\bf u}_1={\bf v}_1 \quad\text{and}\quad {\bf u}_2={\bf v}_2-\mu_{2,1}{\bf u}_1 \quad\text{where}\quad\mu_{2,1}=\frac{{\bf v}_2 \cdot {\bf u}_1}{||{\bf u}_1||^2}$$
Geometrically it is given as

In order to get ${\bf u}_2$ i.e., orthogonal to ${\bf u}_1$ project ${\bf v}_2$ onto ${\bf u}_1$ and the length of the projection on ${\bf u}_1$ is given by $\frac{|{\bf v}_2 \cdot {\bf u}_1|}{||{\bf u}_1||}$ and to get the direction we multiply the length by the unit vector $\frac{{\bf u}_1}{||{\bf u}_1||}$ and the $\mathrm{proj}_{{\bf u}_1} {\bf v}_2= \frac{{\bf v}_2 \cdot {\bf u}_1}{||{\bf u}_1||}\times \frac{{\bf u}_1}{||{\bf u}_1||},$ where the length of the projection is $\frac{|{\bf v}_2 \cdot {\bf u}_1|}{||{\bf u}_1||}$. In GSO process $\mu_{2,1}=\frac{\text{length of the projection of \(v_2\) on \(u_1\)}}{||{\bf u}_1||}$ what does $\mu_{2,1}$ represent geometrically?

If $\{ {\bf v}_1,{\bf v}_2 \}$ is the basis of the lattice to solve the shortest vector problem, our aim is to find the orthogonal basis. But orthogonal vectors computed using GSO need not be a basis because $\mu_{2,1}$ need not be an integer.

Since SVP is a hard problem, the LLL algorithm solves approximate SVP. In defining an LLL reduced basis the first requirement is $\mu_{2,1} \le \frac{1}{2}$ (size reduction condition). What does this imply?


texts: Question about a proof in Junod's paper about the Blum-Blum-Shub generator

texts:
I am reading Junod's paper about the Blum-Blum-Shub generator. There is one thing I just do not understand about his proof of Lemma 4. On page 17  he writes:

We conclude that $x=-x_0$ and from Lemma 1 we know that $x \ne x_0$
(So far I understand.)
, so they must have different parities (Why is this the case?), $n$ beeing odd, which is a contradiction.

Could you please explain that to me?


texts: why IPSec transport mode is restricted for host-to-host communication , or host-to-gateway where gateway acts as a host only?

texts:
Transport mode is allowed between two end hosts only; tunnel mode is required when at least one of the endpoints is a "security gateway" (intermediate system that   implements IPsec functionality, e.g., a router.)
But in case all addresses are public and scalability is not an issue, why transport mode IPsec SAs cannot be used between two security gateways ?


texts: Existence of encryption schemes where $F_{k}^{-1} \big( F_{k}(A) + R \big) = A + O(R)$

texts:
Is there a encryption scheme in literature, where I can do something like

$$F_{k_1}^{-1} \big( F_{k_2}(A) + R \big) = A + O(R)$$

where, $A$ is a $m \times n$ real matrix,  $R$ is a $m \times n$ real matrix that contains some random noise, and (preferably, $k_1 \neq k_2$)

essentially what I want is a scheme where if the encryption of my matrix $A$ 'picks up' some  noise, the decryption should not be heavily effected, and the noise after the decryption is of order $O(R)$

EDIT: Since there has been no concrete answers yet, let's relax the the $k$s.. what if we are willing to have $k_1 = k_2$?


texts: Is there a public-key system that can chain?

texts:
Does there exist any asymmetric cryptosystem that has the following properties:

If I know somebody's public key PBK_1 and my own key pair (PVK_2,PBK_2), I can construct a new public key PBK_3 such that:

 enc(M,PBK_3) = enc(enc(M,PBK_1),PBK_2)

and PBK_3 has the same space and time cost as PBK_1 and PBK_2, or at least doesn't suffer linear blow-up?  Obviously if I can use twice the space and time, I can define PBK_3 = (PBK_1,PBK_2) and so forth.

and (I think this is implied by the above but I'll mention it explicitly) that the plaintext and ciphertext are the same size.

My quick survey of cryptosystems reveals no good candidates.  The Niederreiter cryptosystem looks like it could compose public keys, except that they are rectangular matrices n x (n-k) instead of square.  RSA looks like it could physically represent the composed key, but offers no way to find it without factoring PBK_1.  Others either expanded the ciphertext or couldn't compose keys at all.


texts: Space needed to store an RSA private key

texts:
How much space is actually needed to store a $4096$-bit RSA private key? I originally assumed $0.512$ kB since $\frac{4096}{8} = 512$, but then I started to wonder whether it was in hex.

Simply, what's the size of a $4096$-bit private key, and how does it compare to the public key?


texts:
After doing lots of reading on SO and other websites relating to AES cryptography, I am trying to understand the security issues surrounding IV's.

There seems to be a lot of confusion and contradiction surrounding this subject.

Many say it is safe to publish the IV as it is not a secret whilst others say it should be kept safe AND a secret, as this translates to the starting point for the AES encryption engine using CBC. Without the IV, the decryption of the cipher block will corrupt, so by default shouldn't this add security by keeping it a secret?

Could somebody please help me understand, finally, what the official standpoint is regarding the IV so I don't release my cryptography software with a huge gaping hole in it.

The way I see it, if the IV is the initialiser for the AES engine, surely if a cryptanalyst knows this it will give him a starting point for attacking the cipher text? On the same note, if the IV was kept a secret the cipher text would be even harder to attack as every encryption of a given string (or file) using an IV would produce a completely different cipher block and no 'starting point' is known.


texts: Why derive keys from a master key instead of generating random keys?

texts:
I noticed AWS KMS generates encryption keys based off of a master key, using a key derivation function (HKDF).

What's the practical advantage of deriving keys based on a master key? Isn't it simpler and typically more secure to just generate random keys with a CSPRNG?

Fewer keys to store?

Edit: to add context to AWS KMS, it uses a hardware security module, which would seem to add a storage constraint. However, given KMS basically just generates new data encryption keys (DEKs) and wraps (envelope encrypts) them with the master key for the user to store elsewhere, it doesn't seem to change storage requirements. So it begs the question, why derive the DEKs from the master key?


texts: Diffie-Hellman key exchange using addition instead of multiplication?

texts:
I know that the additive finite group $(Zp,+)$ of prime order $p$ when I perform the Diffie-Hellman key exchange (DHKE) protocol is insecure. I didn't however find many sources online explain why it is insecure. Neither could I find information about what possible attacks can be performed in that case.

Can anybody explain why it is insecure and what possible attacks would be possible if I would use addition instead of multiplication?

Additionally, how can I make both Alice and Bob have the same key when performing the DHKE using $(Zp, +)$?


texts: Strong RSA problem in $\mathbb Z^*_{n^2}$

texts: Comparing to this question, assume $C, M \in \mathbb Z^*_{n^2}$, $e \ge 3$, is it hard to compute $M$ that satisfies $C=M^e \mod n^2$ when $C$ and $(n, e)$ are given?


texts: Does secure hashing imply secure symmetric encryption?

texts:
I was wondering if the mere existence of a (by some definition) secure cryptographic hash function immediately implies an equally secure symmetric encryption scheme.

By my understanding, one could to the following given such a function:

Encryption: Using a shared secret key, we calculate the hash of the key concatenated with the first character of the text, the key concatenated with the first two characters of the text, etc. (every prefix), giving the same number of hashes as characters in the input. This would inflate the size somewhat, but only by a small constant factor.

Decryption: Knowing the key, we can calculate the hash of our key concatenated with every character from the alphabet, and once we find the one that matches the first hash, we can repeat the process with the next hash, until the entire text is found. This would require some more hash calculations than encryption, but only a constant factor, the size of the alphabet (this could be reduced by a bit for bit scheme instead of a character by character scheme).

As far as I know, this incremental series of slightly different inputs to a hash function should not cause the resulting hashes to be predictable, and neither should it leak information about the key.

One weakness I can see is that messages that start out the same and are using the same key will have the beginning of the hash sequence equal up to the point of divergence, but this can easily be mitigated by prefixing the message with a unique ID of some sort, perhaps just a hash of the message itself.

The above is the reasoning that made me think that "hash function" ⇒ "symmetric encryption".

Is there some fundamental principle or scheme that proves/disproves that this is the case?


texts: What cipher mode is suitable for independantly decryptable short messages?

texts:
I'm building a small VoIP client which transmits encrypted audio data via UDP, and some packet loss is expected, so each packet will need to be decrypted separately even if others in the stream don't arrive. I also don't enforce strong ordering of data, since re-ordering is done only if a packet is significantly out of step.

I know some modes like CBC require the previous ciphertext block to be known in order to decrypt the next block, so I don't see that being suitable. ECB is ideal in terms of the "decryptability" requirement, but obviously it's not secure. I figure OFB might be useful, but I can see the implementation being awkward if multiple blocks are skipped.

Are there any modes of operation that suit this kind of scenario, without significant implementation overheads?


texts: Is SHA-1 safe for signing ECDHE parameters?

texts:
Is using the SHA-1 algorithm insecure for hashing the ephemeral ECDH public key in the signed_params structure?

There are some worrying articles about using SHA-1:

Phasing Out Certificates with SHA-1 based Signature Algorithms
Gradually sunsetting SHA-1

My server sends the following Server Key Exchange message for TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b).

TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange
    Content Type: Handshake (22)
    Version: TLS 1.2 (0x0303)
    Length: 148
    Handshake Protocol: Server Key Exchange
        Handshake Type: Server Key Exchange (12)
        Length: 144
        EC Diffie-Hellman Server Params
            Curve Type: named_curve (0x03)
            Named Curve: secp256r1 (0x0017)
            Pubkey Length: 65
            Pubkey: 0...
            Signature Hash Algorithm: 0x0203
                Signature Hash Algorithm Hash: SHA1 (2)  <<<=============
                Signature Hash Algorithm Signature: ECDSA (3)
            Signature Length: 71
            Signature: 3...

Should I change it to use SHA256 like server certificate? Or is it safe since it is used to sign the ephemeral key?


texts: Recovering public key with small R parameter

texts:
I use for tests small toy 16-bit elliptic curve:
Modulus prime p: 65167
a:       0
b:       7
order:   64879
G:      (62171,14828)

(generated by brichard19/ecdl on Github)
I use procedures:
bool Ecdsa16::sign_simple(const uint16_t privateKey, const uint16_t msgHash, const uint16_t nonce, uint16_t &outR, uint16_t &outS) {
    if (nonce==0 || nonce>=CurvePoint16::ORDER) return false;
    CurvePoint16 p = CurvePoint16::G;
    p = CurvePoint16::privateExponentToPublicPoint(nonce);
    uint16_t r = p.x.value % CurvePoint16::ORDER;
    if (r == 0) return false;
    outR = r;
    uint16_t s = (int64_t)reciproc(nonce, CurvePoint16::ORDER) * (msgHash + (int64_t)r * privateKey) % CurvePoint16::ORDER;
    if (s == 0) return false;
    s = std::min((int)s, CurvePoint16::ORDER - s);
    outS = s;
    return true;
}

bool Ecdsa16::verify_simple(const CurvePoint16 &publicKey, const uint16_t msgHash, const uint16_t r, const uint16_t s) {
    if (publicKey == CurvePoint16::ZERO || !(publicKey.z.value==1) ||
        !(publicKey.x*publicKey.x*publicKey.x+FieldInt16(7)==publicKey.y*publicKey.y))
        return false;
    CurvePoint16 checkzero = publicKey;
    checkzero.multiply(CurvePoint16::ORDER);
    if (checkzero!=CurvePoint16::ZERO) return false;
    if (!(0 < r && r < CurvePoint16::ORDER))  return false;
    if (!(0 < s && s < CurvePoint16::ORDER))  return false;
    uint16_t  w = reciproc(s, CurvePoint16::ORDER) % CurvePoint16::ORDER;
    uint16_t u1 = ((uint32_t)msgHash * w) % CurvePoint16::ORDER;
    uint16_t u2 = ((uint32_t)r * w) % CurvePoint16::ORDER;
    CurvePoint16 p = CurvePoint16::G;
    CurvePoint16 q = publicKey;
    p.multiply(u1);
    q.multiply(u2);
    p.add(q);
    p.normalize();
    return r == p.x.value % CurvePoint16::ORDER;
}

bool Ecdsa16::recovery(const uint16_t msgHash, const uint16_t r, const uint16_t s, CurvePoint16 &publicKeyA, CurvePoint16 &publicKeyB) {
    const uint16_t &order = CurvePoint16::ORDER;
    const uint16_t &zero = 0;
    if (!(zero < r && r < order && zero < s && s < order))
        return false;
    FieldInt16 rf(r);
    CurvePoint16 R1(rf);
    CurvePoint16 R2 = R1;
    R2.negate();
    uint16_t rinv = reciproc(r, CurvePoint16::ORDER);
    uint16_t negmsg;
    negmsg = CurvePoint16::ORDER - msgHash;
    if (msgHash>=CurvePoint16::ORDER)
        negmsg+=CurvePoint16::ORDER;
    uint16_t u1 = ((uint32_t)negmsg * rinv) % CurvePoint16::ORDER;
    uint16_t u2 = ((uint32_t)s * rinv) % CurvePoint16::ORDER;
    CurvePoint16 u1G = CurvePoint16::G;
    u1G.multiply(u1);
    CurvePoint16 u2R1 = R1;
    u2R1.multiply(u2);
    CurvePoint16 u2R2 = R2;
    u2R2.multiply(u2);
    publicKeyA = u1G;
    publicKeyA.add(u2R1);
    publicKeyA.normalize();
    publicKeyB = u1G;
    publicKeyB.add(u2R2);
    publicKeyB.normalize();
    return true;
}

I notice, that for some nonces recovery is bad, although verification is good. Bad nonces seems to be random, but r parameter for bad recovery is always small: maximum is 285.
modulus_p - order = 65167-64879 = 288. It is error in my recovery procedure or signing should be bad for nonce which generate small r parameter?


texts: Is it possible to safely implement the Signal Protocol (X3DH) without using XEdDSA

texts:
In the X3DH specification of the Signal Protocol it mentions having a signed pre-key in the key bundle.
This pre-key is signed using the identity private-key.
Because the identity private-key is in the X25519 Montgomery form, it cannot be used as a signing key.
Therefore signal implements XEdDSA to overcome this and converts the Montgomery form key into it's bi-rationally equivalent Edwards curve form, effectively allowing the same key to be used for key exchange and signing.
This is my limited understanding of what's taking place.
However, I'm wondering, is it possible to skip XEdDSA and still securely implement the Signal protocol (albeit modified) by having separate ed25519 keys (Edwards form) only for signing (using EdDSA).
In this situation:

Would the separate (ed25519) public key be sent as an additional
(long term) key in the bundle (same as the identitykey).
Would we only need to continue signing the signed-pre key (using this ed25519 key), or will this introduce the need to also sign additional keys (since our additional signing key no longer matches with the original identitykey, possibly presenting a verification problem).

Reference:
https://signal.org/docs/


texts: Let $N=pq$ where $p$ and $q$ are safe primes. If the adversary knows the inverse of $p$ mod $q$ and the inverse of $q$ mod $p$, can this help him factor $N$ or break the textbook RSA?


texts: Are EdDSA algorithms encoded by ASN.1 DER standards?

texts:
Is it required, or widely practiced to encode a EdDSA signature as a ASN.1 Sequence? Why or why not? How should you encode a EdDSA signature? I cannot find mention of DER or ASN in the EdDSA RFC.

However, there is mention in the ECDSA RFC (as expected)

  An ECDSA signature is a pair of integers.  In many protocols that
     require a signature to be a sequence of bits (or octets), it is
     customary to encode the signature as an ASN.1 SEQUENCE of two INTEGER
     values, with DER rules.


texts: PHP AES-256 CBC faster than AES-128 CBC?

texts:
For the last couple of days, I have been learning a bit about encrypting data in PHP, as I need a good encryption/decryption function for storing users' passwords in a DB. I use openssl_random_pseudo_bytes() for the IV, hash_hmac with SHA256 and openssl_encrypt(). Here's the function for encryption:

// 32 bytes (256-bit) (64 char) encryption key
define('ENCRYPTION_KEY', 'd027e7*+7b6d5fcd55f4b5c32611b87cd923e88837b63bf2941ef819dc8ca282');
// 16 bytes (128-bit) (32 char) encryption key
define('ENCRYPTION_KEY2', 'b6d5fcd55f4b5c32611b87cd923e88ae');
function pw_encrypt($encrypt, $key, $type){

    $hmac_key = 'd027e7*+7b6d5fcd55f4b57su921b87cd923e88837b63bf2941ef819dc8ca282';

    $encrypt = serialize($encrypt);

    $method = "AES-$type-CBC";

    $isCryptoStrong = false; // Will be set to true by the function if the algorithm used was cryptographically secure
    $iv = openssl_random_pseudo_bytes(openssl_cipher_iv_length($method), $isCryptoStrong);

    if(!$isCryptoStrong)
        throw new Exception("Non-cryptographically strong algorithm used for iv generation. This IV is not safe to use.");

    $mac = hash_hmac('sha256', $encrypt, $hmac_key);

    $passcrypt = openssl_encrypt($encrypt.$mac,$method,$key,OPENSSL_RAW_DATA,$iv);
    $encoded = base64_encode($passcrypt).'|'.base64_encode($iv);

    return $encoded;
}

So I've run this bit of code to test AES-128/-256 with 128 bit / 256 bit encryption keys. Now the thing that bothers me that AES-256 seems faster than AES-128, is that normal?

Here are the results-- times are usually something similar to this:

$data = '&>tsX@(3BjsAepZW';
Encrypted Data AES-128 128bit key: Length: 153 Total Execution Time: 2.6027361551921E-6 Mins
Encrypted Data AES-128 256bit key: Length: 153 Total Execution Time: 1.8000602722168E-6 Mins
Encrypted Data AES-256 128bit key: Length: 153 Total Execution Time: 1.7166137695313E-6 Mins
Encrypted Data AES-256 256bit key: Length: 153 Total Execution Time: 1.7166137695313E-6 Mins

So, what bugs me:

Am I doing something wrong here, or is AES-128 really slower than AES-256?
How come the length of encoded string is in all 4 cases the same?
Does the encryption key have to be in HEX format or can I use *+/-_.,'?
The key for has_hmac, should it be randomly generated or just as I have it, predefined? If random, what's the best pratice for creating a random key? And what length and type should it be (hex or +*/-'.?)?


texts:
Is there a fast algorithm for mapping $n$-bit numbers $s$ (for fixed $n$) into a cyclic subgroup of an elliptic curve (over a finite field) in which the Discrete Logarithm Problem is hard?

By fast, I mean it takes about as long as a point addition (and is much faster than a point scalar multiplication in the elliptic curve group, or an exponentiation operation in the finite field).

The mapping: $s \rightarrow s \cdot G$, for some generator $G$, would be too slow, and also would defeat the security of construction since the discrete logarithm with respect to $G$ would be known.

It is not necessary for the running time to be independent of the input.  For instance, for elliptic curves defined by

$y^2 = x^3 + ax + b$

over the finite field $F_p$, there is the standard method of setting $x = s \bmod p$, and then computing the square root of $x^3 + ax + b$.  If $p = 3 \bmod 4$, then we can compute the square root using exponentiation in the finite field.  If the square root does not exist, we increment $x$ and try again.  In this way we can obtain a point in the elliptic curve group, and if our cyclic subgroup has cofactor 1, then we are done.  This method would be valid except that computing the square root via exponentiation takes significantly more time than a point addition.

Is there some method/choice of elliptic curve that allows a much more efficient mapping to be defined?

The speed I'm looking to beat (in order for this construction to be faster than an alternative that does not use elliptic curves) is around 100000 operations (hashes to curve points) per second on a standard single CPU core (e.g. 3.2GHz Nehalem) with a 256-bit elliptic curve.  Testing with libsecp256k1, which seems to include an optimized square root implementation, I can compute only about 77000 square roots per second.


texts:
I am using FIPS based OpenSSL module for encryption of sensitive data for my desktop socket server and client applications. I am using ECDH for key agreement.The keys public and private pair is generated for server and client on same curve NID_secp521r1. Now I want to exchange the public key between client and server and has following questions.

The generated private key is same for both client and server is it true? Client send its public key first or Server? The public key should be send plain or it should be signed? If signed then what will be the mechanism? I want to reuse my public/private key on server where I store that keys in application exe? PEM file? Any other options?


texts: Does having a hash of a password jeopardize the security of plaintext that was encrypted with that password?

texts:
A malicious actor wants to decrypt ciphertext that was encrypted with a password. He also possesses the hash (bcrypt/PBKDF2) of that password. Does he have any significant practical advantage in decrypting that ciphertext as compared to just having the encrypted ciphertext (with no hash)?

I believe that the clear advantage would come from the ability of being able to do a dictionary attack, since the guessed passwords could be deterministically checked against the hash. However, I could not find or come up with any other advantage. How does this change the situation if the password used is stronger (making dictionary attacks less dangerous)?


texts: An aggregate signature scheme for transactions

texts:
Suppose A and B communicates where A makes B some payments by sending signatures  as the following,
$$ \sigma_1 \leftarrow Sign(v_1, sk_A), \sigma_2 \leftarrow Sign(v_2, sk_A), \dots \sigma_n\leftarrow Sign(v_n, sk_A).$$
That is, A has made B $n$ payments where he paid $v_1$ in payment 1, $v_2$ in payment 2 and so on.
Let's say B wants to collect his money from a bank by sending these signatures as proof.
Can he generate a single signature such as $\sigma_{agg} \leftarrow Sign(\sum_i v_i, sk_A)$ out of the
individual signatures that he has?
The goal is to hide the number of transactions as well as the payment amount in each from the bank in this case.


texts: Encryption with "constant" initialization vector considered harmful

texts:
I try to get the full reasoning behind the above statement. First, after reading articles here and at wikipedia i understand that using an IV only once is good practice.

For stream ciphers not doing so will result in compromising security because of

Cipher1 xor Cipher2 = Plain1 xor Plain2

For block ciphers using the same IV will degrade to ECB mode.

But, is there a real attack like with the stream cipher (or does the stream cipher reasoning apply, too)? E.g. if i have two (short) messages, create a single IV, encrypt both using AES and save the three values for later decryption - what is a concrete attack?

A concrete example from a fictious "preferences vault" implementation. Having an xml like

<vault>
    <items>
        <item iv="" name="f2e342435" value="2034b324">
        </item>
                ...
    </items>
</vault>

where iv is the initialization vector for encrypting both name and value properties, would this add any vulnerability in comparison to having two iv's (always assuming AES).


texts: What is the difference between authenticating and signing a document?

texts: Authenticating a document means to verify it is from the sender. But it seems like signing a document also verifies it’s from the sender. What exactly is the relationship or difference between “authenticating a document” and “signing a document”? Are they the same thing?


texts:
Consider the following setting.

Alice receives a chunk of data from Victor, together with a cryptographic certificate of authenticity of some sort (eg hash signed with Victor’s private key).

Bob now wants to know the result of some computer program applied to the data. Alice is not willing to disclose the raw data to Bob, but is happy to perform the computation herself and send him the result. The program was not known at the time Victor certified the data.

Is there a scheme that will allow Bob to verify that the computation was in fact performed as agreed, on the data certified by Victor?


texts: What differentiates a password hash from a cryptographic hash besides speed?

texts:
I understand that password hashes like bcrypt have the principal property of taking a long time to run, but I'm wondering what if anything about password hashes make them superior to merely running a fast cryptographic has a bunch of times.

In particular, why does bcrypt exist when I can just run SHA-256 100000 times? Furthermore, it seems relatively extensible to adapt to increases in computing power. When computers get 100000 times as fast as they are today, I can just reapply the hash to my password hashes 100000 times and at verification time run SHA-256 100000*100000 times to validate a password attempt. Are there flaws in this naive approach. Are there other properties of password hashes that make them particularly suited to hashing passwords? Lack of parallelizability, space complexity, something else?

My question comes about when analyzing a prominent response to the June 2012 incident in which 6 million password hashes were stolen from LinkedIn. In the article, the author emphasizes the value of using a password hash instead of a fast cryptographic hash in validating user passwords. I understood the basic argument for having a hash that's slow but failed to glean from it particular advantages of "password" hashes that made them distinct.


texts:
I have a system which (should) never shut down, there are keep alive messages every 30 seconds and normal traffic is very variable, might be a few KB/sec might be nothing more than the keep alive message.

Normally one would create a new key when you start a new connection but since our connection could (should) be up for weeks or months there is not standard re-negotiation for a session key.

My question is how much time should be between the generation of a new session key? should it be every day at midnight? or would that make the system vulnerable if the negotiation for a session key is always on the same time (or after a set time frame). Does TLS have something for this?

extra
Renewing a masterkey for our scenario is a bit tricky, we could do this by going to all the devices and manually setting it, something we would like to avoid. But it will be necessary to renew a master key once in a while, how often should you do that? given that it will be quite difficult to do.

EDIT
There is no DH or ECDH, well not in the first versions anyway. I am trying to push it (and certificates). A problem the company has is that we assume DH and ECDH will take to much time on our devices (we only have a few milliseconds to work with (about 10 to 15 ms) ) and I have not looked into the DH and ECDH times. on our Renessas controler (about 100 Mhz)


texts: How to implement a hash function $H \colon \{0,1\}^* \to \mathbb{Z}_p^*$?

texts:
I would like to implement a hash function $H \colon \{0,1\}^* \to \mathbb{Z}_p^*$ such that $p$ is a prime number and $\log_2(p) > 256$. I am wondering if it is a good idea to use the hash function SHA-256.

Since $\log_2(p) > 256$, can I just use the output of SHA-256 and apply the modulo $p$ on it?

I would also like to prevent the all-zero (0000…0000) output from SHA-256, is it correct for example to add the value $1$ to the output of SHA-256? Is there a better way?


texts: Is there a secure way of allowing users of my app to selectively share data from an external service?

texts:
Is there a secure way of allowing users of my app to selectively share data from an external service with my app?
In order for the users of my app to get their personal data from the external service they need a private key for the external API.
Is there any secure method of allowing the user to share some of their data from the external service without having the user expose their keys with my app?
I thought perhaps end to end encryption could be a potential solution. Thoughts?


texts: Comparison among algorithm based on key length

texts:
Some months ago I found in some paper that we cannot compare symmetric algorithm with asymmetric algorithm based on the key length and more important we cannot compare asymmetric algorithm using only the key length, while a comparison of only symmetric algorithm in this term is reasonable... I explained it basing on the fact that:

in symmetric encryption algorithm the key length identifies the number of attempts necessary to decrypt the communication in both way, while in asymmetric encryption we are not sure that for a key of n bits, we will use all the possible numbers, so using ONLY  the key length as a term of comparison is not sufficient, we could have key of 300 billion of bits but available only 2...

My question so is: is it true that all the possible symmetric algorithm uses all the possible numbers of n bits as possible keys or among these there are some of that not usable?

Thanks


texts: Is ChaCha20 safer than AES with respect to side-channel attacks?

texts:
I've already seen some topics on this matter, but I feel like my question hasn't really been answered.

Given the following:

AES must be implemented in hardware (i.e. using the AES-NI instruction set) to ensure the best protection against side-channel attacks that target the algorithm's implementation (because of MixColumns operations)
Other encryption algorithms such as the Salsa20 family and NORX are less prone to such issues (if well implemented, at least in software)

...can we say that it is safer$^1$ to use such algorithms instead of AES if one may not ensure that AES-NI is properly implemented in the hardware that's being used ?

For instance, if one uses some x86-64 CPU that features this instruction set but whose design is kept secret, can AES be considered safe ? Respectively, are the other algorithms safe(r) on such a platform ?

$^1$Note that NORX is still in its early stages and has yet to win the CEASAR competition as well as withstanding the test of time, so it is only safe "on paper" for now


texts: Which risks are associated with deriving multiple keys from the same DH secret Z?

texts:
NIST recommends Krawczyk's HMAC-based key derivation function (HKDF) in SP-800-56C (PDF). HKDF shall e.g. be used to create keys from shared secrets after Diffie Hellman key establishment.

NIST states in the same doc:

  Each call to the randomness extraction step requires a
  freshly computed shared secret $Z$, and this shared secret
  shall be zeroized immediately following its use in the
  extraction process.

Why is it not recommended to derive multiple keys from the same $Z$, e.g. why not derive a key for data encryption and a key for authentication from the same $Z$ using different info strings? If I still do it, what weaknesses might the derived keys be facing? Is it simply bad practice (without deep explanation) to do so since the derived keys obviously are related? Krawczyk seems to think that multiple derivations from the secret are expected use (see section 3.2 in RFC 5869, my interpretation).

Does salting the HKDF with a good random salt change my risks when deriving multiple keys from a single $Z$?