texts:
Throughout history, some cryptographic systems were broken by finding patterns in encrypted messages (like frequent chars in a particular language), and thereby discovering the cipher. These classic systems, which relied on algorithms unknown to the attacker, were broken by analyzing the messages and detecting patterns. This allowed attackers to induce the algorithm that was used.

The security of modern cryptography is based on a large key and applying non-reversible mathematics to a message to obtain an encrypted message. In these modern systems it is impossible to apply reverse engineering to a message because it requires more computational capacity than available.

Since there is currently a lot of storage capacity to store an giant amount of encrypted messages, knowing that it was generated with the same key and the same algorithm, it is not possible to analyze them, for instance by finding repetitive patterns, to be able to deduce the key?


texts:
In his writeup of the Solitaire keystream generator algorithm, Bruce Schneier warns not to use the same key for two different messages:

  The first rule of an output-feedback mode stream cipher, any of them,
  is that you should never use the same key to encrypt two different
  messages. Repeat after me: NEVER USE THE SAME KEY TO ENCRYPT TWO
  DIFFERENT MESSAGES. If you do, you completely break the security of
  the system. Here's why: if you have two ciphertext streams, A+K and
  B+K, and you subtract one from the other, you get (A+K)-(B+K) =
  A+K-B-K = A-B. That's two plaintext streams combined with each other
  with no key involved, and is very easy to break. Trust me on this one:
  you might not be able to recover A and B from A-B, but a professional
  cryptanalyst can. This is vitally important: never use the same key to
  encrypt two different messages.

Intuitively, this makes sense, but as he said, I'm not able to recover A and B.

What sort of attack is he talking about?


texts: Second challenge in Fiat-Shamir for 5-round schemes

texts:
I'm not sure how to compute the second challenge when applying FS to a 5-round protocol. I've seen TWO different formulas (with and without including the first challenge) and don't know which one is correct.

Suppose we have 5-round interactive protocol for some statement $st$:

$P$ → $V$: $x$ means prover sent $x$ to verifier.

$P$ ← $V$: $y$ means verifier sent $y$ to prover.

$P$ → $V$: $\alpha_1$ // 1st commitment
$P$ ← $V$: $ch_1$  // 1st challenge
$P$ → $V$: $\alpha_2$  // 1st answer
$P$ ← $V$: $ch_2$ // 2nd challenge
$P$ → $V$: $\alpha_3$ // 2nd answer

Now we can apply Fiat-Shamir transform to get a non-interactive proof.

Question: how we compute $ch_2$?:

a) $ch_2 = Hash(st|\alpha_1|\alpha_2|aux)$

b) $ch_2 = Hash(st|\alpha_1|\alpha_2|ch_1| aux)$ ← includes $ch_1$

On the one hand, $ch_2$ should be independent of $ch_1$, right? An original article of Pointcheval and Stern[2], article by Kiltz et. al[1], plus some answers here use formula a.

On the other hand, there are articles [3],[4] where the formula b is used.

UPD: Will the fact of whether $ch1$ included or not matter for the Forking Lemma?

[1] Tightly-Secure Signatures from Five-Move Identification Protocols by Eike Kiltz, Julian Loss, and Jiaxin Pan https://eprint.iacr.org/2017/870.pdf

[2] Security Arguments for Digital Signatures and Blind Signatures by David Pointcheval and Jacques Stern https://www.di.ens.fr/david.pointcheval/Documents/Papers/2000_joc.pdf

[3] From 5-pass MQ-based identification to MQ-based signatures by Ming-Shing Chen, Andreas Hülsing, Joost Rijneveld, Simona Samardjiska, and Peter Schwabe https://eprint.iacr.org/2016/708.pdf

[4] Extended Security Arguments for Signature Schemes by Sidi Mohamed El Yousfi Alaoui, Özgür Dagdelen, Pascal Véron, DavidGalindo, Pierre-Louis Cayrel https://hal.inria.fr/hal-00684486/document


texts: Mapping a value $g^x \bmod p$ to a small interval $[1...H]$

texts:
My question is in $\mathbb{Z}_p^{*}$ context, where $p=q\cdot k+1$ for two primes $p,q$ and $k \in \mathbb{Z}$; $g$ is the generator of the subgroup $G_q$ of $\mathbb{Z}_p^{*}$, of order $q$.

Let's consider a small $H$ (e.g. $H=1024$) and a specific $h \in \mathbb{Z}_p$, with $0 < h < H$, and we randomly choose $g \in \mathbb{Z}_q$: is it true (I hope it is) that it is easy to find a $x$ such that $h \equiv (g^x \bmod p) \bmod H$?

My concern is: is it possible to create a mapping from a randomly chosen $g^x \bmod p$ that can be mapped to a target (desired) value $h$ in a small range, such that we can find it easily, e.g., in $\mathcal{O}(H)$?


texts:
For the PDP scheme, I need to generate the following parameter:
g is a generator of Q (Q is the set of quadratic residues modulo N (N = pq is the RSA modulus)
What algorithm can be used to generate this parameter most effectively?


texts:
NORX replaces all the additions of the Chacha20 quarter-round function with the non-linear $x \oplus y \oplus ((x \land y) \ll 1)$ operation. Gimli supposedly improves on it with $x \oplus y \oplus ((z \land y) \ll 1)$, adding a third input $z$ because as they claim it removes the need for the additional xor that NORX has. In addition the Gimli paper says "Gimli varies the 1-bit shift distance, improving diffusion compared to NORX and possibly even compared to ARX".
So we end up with
$$
  a \gets z \oplus y        \oplus ((x \land y) \ll 3) \\
  b \gets y \oplus x        \oplus ((x \lor z) \ll 1) \\
  c \gets x \oplus (z \ll 1) \oplus ((y \land z) \ll 2)
$$

My issue with this is that nowhere in the Gimli specification (as far as I could tell anyway) it explains why they did $z \ll 1$ or why they used bitwise or in $x \lor z$ nor does it explain the exact parameter choices for the non-linear operation (why $a \gets z \oplus y        \oplus ((x \land y) \ll 3)$ rather than $a \gets z \oplus x        \oplus ((z \land y) \ll 3)$ for example).

Is there any justification for these changes that I might have missed?


texts: Benefit of combining classical substitution ciphers with modern cryptography

texts:
I know that a simple monoalphabetic substitution cipher is considered extremely weak, on account of linguistic frequency-analysis attacks.  However, assume the following:

cleartext is encrypted (with 256-bit AES, for example), and the resulting cipher is in base64 format
the client has a key of 64 chars (a-z, A-Z, "+/"), where each character is randomly mapped to another character (i.e., 'a' -> 'Y', 'b' -> 'f', 'c' -> '/' etc)
a simple monoalphabetic substitution cipher is applied to the base64 ciphertext

Aside from the practicalities of implementing this approach, would this add much security?  I argue that it would, taking into consideration the following points:

neither base64 encoded text nor the raw encrypted data it represents are subject to frequency-analysis attacks
the 'key space' (to use the word loosely) of the base64 character set, represented as a factorial (64!) = 1.2688693e+89, or roughly 2^296 (if I calculate correctly).

So, in the case of a brute force attack, an attacker would need to try 2^296 key combinations, and for each one of those, they would need to go through the normal process of brute-forcing a 256-bit AES cipher (already unfeasible).

In the case of a break in the underlying algorithm (AES, in this case a break would be highly unlikely) the attacker would still need to search the 2^296 keyspace to find the original ciphertext.

There has been plenty of discussion about double-encryption, and how it adds little more security (in terms of orders of magnitude), but I would like to know people's thoughts about the approach described above.  I DO understand that it's complete overkill, and that 256-bit AES encryption is more than sufficient by itself, but I'm interested to hear opinions at least from a theoretical point of view.  Does this potentially add much security?


texts: Differences between HMAC and HKDF in a specific case

texts:
I want to use a key derivation function to derive a key from another one.
I think HKDF is the easiest solution in my case.
This explanation gives a clear definition of HKDF.
In the case where the number of key bits requested from the KDF is equal to the hash output length (i.e. L = k in the definition), do I have to compute 2 HMACs:
PRK = HMAC(XTS, SKM) and K(1) = HMAC(PRK, CTXinfo)
or can I directly compute:
K(1) = HMAC(SKM, CTXinfo) ?


texts: Cryptographic properties of field multiplication (Continued)

texts:
This question follows-up from this question/comment.
Suppose, you are given $X \odot Y$, where $X~(\neq 0) \in \operatorname{GF}(2^{128})$ is random, $Y~(\neq 0) \in \operatorname{GF}(2^{128})$ is random, and $\odot$ is a multiplication over $\operatorname{GF}(2^{128}$) with some modulus. As explained in this answer, the product $X \odot Y$ preserves privacy about its factors.
Therefore, assume you are given some extra information (see below). Will it be possible to recover (at least some non-trivial information) $X$, $Y$ under each of the scenarios:

$X \oplus Y$ is given. Since $\oplus$ can be stated as the addition operation over any $\operatorname{GF}(\cdot)$, we can also say the sum of $X$ and $Y$ over $\operatorname{GF}(2^{128})$ is given.
Arithmetic sum $X + Y$ is given.
Modular addition, $X+Y \pmod{2^{128}}$ is given. Or, may be with any other divider (except $2$ as this coincides with $\oplus$), say $2^{8}$ or $2^{16}$, instead of $2^{128}$.

I considered each of the above scenarios to be exclusive. Please feel free to combine the scenarios or propose a new scenario if that is useful.


texts: How are the AES inverse S-Boxes calculated?

texts:
I would like to know, how to calculate the inverse S-box.
I followed this
link (with affine transformation first, then multiplicative inverse), but the result is wrong. For example, if I use the value 0x52 (01010010 in binary), reverse of this value would be 01001010.
The inverse matrix (for inverse S-Box) is:

Input = 0  1  0  0  1  0  1  0 (LSB First)
Row 0 = 0  0  1  0  0  1  0  1
Bit 0 = 0  0  0  0  0  0  0  0 = 0

Row 1 = 1  0  0  1  0  0  1  0
Bit 1 = 0  0  0  0  0  0  1  0 = 1

Row 2 = 0  1  0  0  1  0  0  1
Bit 2 = 0  1  0  0  1  0  0  0 = 0

Row 3 = 1  0  1  0  0  1  0  0
Bit 3 = 0  0  0  0  0  0  0  0 = 0

Row 4 = 0  1  0  1  0  0  1  0
Bit 4 = 0  1  0  0  0  0  1  0 = 0

Row 5 = 0  0  1  0  1  0  0  1
Bit 5 = 0  0  0  0  1  0  0  0 = 1

Row 6 = 1  0  0  1  0  1  0  0
Bit 6 = 0  0  0  0  0  0  0  0 = 0

Row 7 = 0  1  0  0  1  0  1  0
Bit 7 = 0  1  0  0  1  0  1  0 = 1

The result is 01000101, MSB first that would be 10100010, XOR-ed with final vector 0x52 is 0xf0. The inverse of 0xf0 is 0x5b, which is wrong. It should be 0x48. Where did I make a mistake?


texts: What is an approximate length for a digital signature (SHA) in this case?

texts:
What is an approximate length for a digital signature (SHA) given the following?

Using RFID tags, size ranging from 100 to 2000 bytes (8000 bits), our project is setting aside a portion for a digital signature against its fixed data, which includes an unique 8-byte serial number and with 32 to 64 bytes of factory data.

The signature, obviously longer leads to more security, will be for authentication (repudiation is not important).  As the fixed data and signature can consume a sizable percentage of the tags, and 2013 technology being what it is (signature can't be too short), I looking to approximate the minimal size needed to securely authenticate data.

Example tag allocation
Fixed data 64 bytes
Unique Serial Number 8 bytes
Digital Signature ?? (32 - 64+ bytes, 256 - 512+ bits)  I'm thinking 64 bytes, but that takes a good chunk of space - maybe overkill.

A prompt answer is not required.

To authenticate 64+8 bytes, what minimal digital signature length is recommended?


texts: With ECDSA is there a way for the verifier to calculate any properties of $k$?

texts:
With ECDSA, given $(r,s)$ and $m$, is there a way for a verifier to calculate any (boolean) properties of $k$, without knowing $k$ or the private key $D_A$?

(I understand that $k$ should be random, or follow RFC6979, but I'm curious.)

In particular, could the verifier compute, given a signature $(r,s)$ and a message $m$, that:

$k$ is odd
$k$ has some mathematical relation to one of the curve parameters
$k$ has some mathematical relation to the public key $Q_A$
$k$ has some mathematical relation to the (truncated) message hash $z$
$k$ was deterministically generated with RFC6979 https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#cite_note-4

for the value of $k$ which was used to generate the signature.

(Variable names taken from https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)


texts: If the hash of the multiplication is equal to the multiplication of the hash, how can this be used to leverage an attack?

texts:
Assume a hash function $H:\left\{0,1\right\}^*\to G$ where $G$ is a group and assume that finding an inverse in $G$ is easy.

How can a preimage efficiently be found using the fact that $H(M_1\cdot M_2)=H(M_1)\cdot H(M_2)$ for $M_1,M_2\neq0$?

I've tried playing around with the group properties but I haven't gotten very far. Any direction would be appreciated.


texts: Can string lookups be vulnerable to timing attacks like array lookups are?

texts: Per “Can non-assembly crypto libraries truly be secure against timing attacks?”, array lookups are vulnerable to timing attacks. Like, if you do cresult[map[i]] and map is an array and cresult, is a string then map is vulnerable to timing attacks because it's an array but is cresult?


texts: is there any hash collision attack that is not defeated by adding a salt first?

texts:
In the references I've read, all the uses of "collision attacks", whether classical collision attack or chosen-prefix collision attack, goes like this: "Alice creates a 'good' document and an 'evil' document that have the same hash.  Alice presents the 'good' document to Bob, who signs it by taking a hash of the document and signing the hash.  Alice now swaps out the 'evil' document and Bob's signature will still appear valid."
But aren't these attacks trivially defeated if, instead of taking the hash of the document, Bob adds a random salt, hashes the document plus the salt, and then signs the concatenation of the hash and the salt?  Is there any set of conditions where this defense would not work?
Because I see lots of sources saying you have to stop using SHA-1 due to the known collision attacks, and by the above reasoning, I don't understand why, when you could just add a salt to whatever you're hashing.
(I have also read about how specific implementations can protect against collision attacks by using the hash function as an HMAC, i.e. adding a salt.  My question is more general -- is there any case where a collision attack is not defeated by adding a salt?)


texts: Calculate new hash from old hash + appended string

texts:
If I have a hash of some string in the form: hash(UNK + "known"),
Is there a way to calculate the hash of (UNK + "known" + "append"), given the hash of the original value?

Specifically I'm asking about the sha512 algorithm.

Basically, I'm asking if the algorithm works by hashing the old hash + new input, or if it only hashes the input by itself.

Thanks!


texts:
I'm evaluating the performance of NTRU; and I got confused. the key size is said to be smaller than RSA but larger than ECC.

Using both the reference implementation when I choose APR2011_439 setting from BC I've thought that 439 would represent the key size in bits. But when I store the public key in byte array its size if 604 bytes (PKCS1Encoding encoding). I'm very consufed. With APR2011_439 I can encrypt blocks of max 54 bytes in size so that would indeed be the key size. But why does the key stored in a byte array take a huge ammount of 604 bytes? It is the same with reference implementation.
Please explain I'm very short on time.


texts: What is the best current way to cryptographically secure databases?

texts:
I'm currently working on a proposal for some secure complete system and one of the things currently lacking is the database security.
However I don't want to roll my own crypto there and thereby need a secure, somewhat reviewed / standard way to cryptographically secure the databases.
I had a look at CryptDB for this but it lacks authentication which I consider needed and I couldn't easily find out what ZeroDB provides except "end-to-end" encryption.

What is the best cryptography based database currently specified / available?

My definition of "best" in this case: Provides authenticity and secrecy (most important), provides integrity over the whole database (no silent dropping of data), leaks as less information to the server as possible, doesn't have to hide access patterns, allows for complex (cryptographically enforced) access rules.

It can be assumed that the clients do use / own public / private key pairs and / or passwords and everyone without valid keys is considered an adversary to the data he doesn't have access to, i.e. attackers may not undetected modify, add or drop data or being able to read the data if they have compromised everything except the client.

The server should hold the only copy of the database and should not have to give it out (due to size) if possible. As for the API, more standard APIs (SQL?) are preferred but custom ones are also acceptable as long as they support the usual queries (like ZeroDB and CryptDB do).


texts:
I would like to make sure I understood HMAC. Wikipedia declares it like:

$$\operatorname{HMAC}(K,m)=H((K\oplus\text{opad})||H((K\oplus\text{ipad})||m))$$

If I want to use HMAC-SHA1, am I correct to say that:

Let's say I take key length of 16 bytes. Does it mean that according to Wikipedia I must pad the key with zeros from right up to 512 bits? (block length of SHA1)
$\text{opad}$ must be a 512 bit value, like: 0x5c...5c (512 bits)?
$\text{ipad}$ similarly: 0x36...36 (512 bits long)?
What to do with $m$ if its length is not 512 bits?
What is the recommended length of actual key and what is the recommended way to generate it?
Is it bad idea to implement HMAC myself, if I have implementation of SHA1?


texts: Prime Factorization in RSA always leads to the product of two primes?

texts:
Lets prime factorize $30$:

$$30 = 3 \cdot 10 = 3 \cdot 2 \cdot 5$$

We see that the number $30$ is a product of $3$ primes. But in RSA, when factorizing huge numbers, we always seem to only get two primes. Why is this??


texts: Additive homomorphic encryption over small fields

texts: Are there encryption schemes that are additively homomorphic with respect to small fields such as $\mathbb{F}_{2^4}$ or $\mathbb{F}_{2^8}$?


texts: One time pad: why is it useless in practice?

texts:
The symmetric cryptosystem one-time pad (OTP) seems to be very beautiful since it is perfectly secret according to Shannon. Many books, however, point out the main drawback: one must create a secret key the same length as the plaintext. For this reason, the concept of perfect secrecy has these days been abandoned, and we prefer other cryptosystems.

Now, for example, suppose I want to encode my text message with the ASCII scheme, and moreover suppose that this plaintext is 10 gigabytes long, therefore (using an OTP) the key must be the same length, 10 gigabytes. I think, however, this is a ''sustainable price'' because I'm sure that the ciphertext can't be attacked.

Practically, I don't understand why having such long keys with an OTP is a big disadvantage if we reach "the dream"-- namely, perfect secrecy. Nowadays the storage of information is very easy, so what is the real problem? I can, for example, share the "long key" in person.


texts: Lattice attacks against Multilinear Maps [CLT13]

texts:
I am currently studying an article on a construction of Multilinear maps. There are some attacks on the scheme presented by the authors and I got stuck at the one in section 5.1.

I will try to summarize the ideas presented there and ask the questions in the end:

Consider the product of $n$ secret distinct primes $p_i$, publish $x_0 = \prod_{i=1}^n{p_i}$.
Given a set of $\tau$ integers $x_j \in Z_{x_0}$ such that $x_j \text{ mod } p_i = r_{i, j}g_i$ the goal is to recover (some of) the values $\textbf{r}_{i} := (r_{i, j}g_i)_{1\le j \le t}$

The attack works as follows: Compute the orthogonal lattice $L$ spanned by some subset $\textbf{x} = (x_j)_{1 \leq j \leq t}$ with $n \lt t \leq \tau$ and apply LLL algorithm on $L$. This results in a reduced basis $(u_1, \dots, u_t)$.

Now, because all vectors $\textbf{u} \in L$ are perpendicular to $\textbf{x}$, namely $\textbf{u} \cdot \textbf{x} = 0 \text{ mod } x_0$, reducing the expression modulo $p_i$ gives that  $\textbf{u} \cdot \textbf{r}_i = 0 \text{ mod } p_i$. Assuming that the product of norms of vectors $||\textbf u||$ $||\textbf r_i||$ is smaller than $||p_i||$ then that equation can be solved in $\mathbb{Z}$.

What I don't understand is:

The conclusion of authors that the vectors $(\textbf u_1, \dots, \textbf u_{t - n})$ resulted by LLL reduction on $L$ are perpendicular to $\textbf r_i$. If this is true, then computing $\textbf r_i$ can be done by Gaussian Elimination in $\mathbb{Z}$.
How does one get such samples $x_j$, namely encodings of zero on the level zero?


texts: Adding bit constants to the key schedule to reduce rounds?

texts:
Bit constants are often added to the key schedule to reduce slide attacks.  I have reviewed David Wagner's work, where he showed that the increased rounds in a Feistel network do not help if you have key symmetry.  I have been trying to find some work that describes if a round-based bit-constant stream could be used to reduce the rounds and not hinder the safety margin.

For instance, let's say that you had a cipher that had 36 rounds, and you can attack 32 of them, where the key schedule contained a round-based constant stream based on an LFSR.  Could round-constants be used in different places to allow the same fundamental architecture to be used in 32 rounds where you can attack up to 28?  I've been unsuccessful in finding something like this in literature.

My motivation behind this is that there are a lot of ciphers out there, and some of them would be better for actual hardware implementation if they were a few rounds shorter.  If I have a 32-round cipher, I can easily just use a shift register to control the rounds.

The question: has anyone looked at taking a cipher that existed and decreased the round requirements without ruining the cryptographic performance by the addition of bit constants per round?

Addendum 1:
I've been exploring this question a little bit as continued literature searches haven't found anything that's helpful.  Slide attacks invalidate the idea that even simple round functions are strong even with many rounds.  I looked at this with SIMON32/64 because it has the simplest round function that I know combined with the fact that I wrote a simulation framework for them so I could tweak the code.

Firstly, it makes me wonder why slide attacks weren't invented earlier, as the image above shows how wonderfully symmetric the simple key schedule just happens to be with the LFSR input.
Secondly, as the strength of the cipher largely depends on the key rounds, it makes me more convinced that someone has looked at reducing rounds in already existing ciphers by modifying the key schedule a bit.


texts: How many field operations are needed when you compute kG in elliptic curves with a multiple additions or the double-ans-add-algorithm?

texts:
For an assignment, we have to calculate how many field computations are needed to calculate kG in an elliptic curve. They want us to show this for two different ways of calculating kG. The first way:

2G = G+G

3G = 2G + G

...

kG = (k-1)G + G

The other way is the double-and-add algorithm.

The question:
Compute how many field operations (multiplications, additions, subtractions, divisions) we have to execute for both algorithms, assuming that we use affine coordinates for the elliptic curve.

I ran into some problems while trying to answer this question and I cannot quite seem to find the answer here or on some other part of the internet (I have to admit I'm not that good at googling).

Can anyone help me with this?
Thanks in advance


texts: Is the $\ell$-Diffie Hellman Inversion easy when g is known?

texts:
From here they define the $\ell$-Diffie Hellman inversion problem as:

  Given $g^{a},g^{a^2}\ldots,g^{a^{\ell}} \in G$, compute $g^{a^{-1}}$

Would this problem become easy if the generator $g$ is also known?


texts: Different encryption standards and how they relate to auth and algorithms

texts:
The main confusion I have is around the different PKCS and relation with SSL (TLS). I have done a lot of research and have found bits and pieces but not necessarily how these relate, so let me explain but first with a little background.
To start, I am fairly comfortable with how SSL (and subsequently TLS) works, and subsequently mutual TLS. Typically X.509 certs with CA signed for mutual authentication, and sometimes using self signed certs. Also with how the symmetric key is used for the content encryption and the asymmetric key is used for encrypting the symmetric key.
I am also fairly comfortable with PGP, encrypting, signing, different algorithms, features like built in zip compression, etc. Particular interest in RSA encryption and signature algorithms, but more on that later. So, so far we have SSL which security can be enhanced if you encrypt a payload before using the transport level encryption, especially if you're sending data somewhere where you don't want any data to be unencrypted at rest.
Now on to PKCS where it starts to get a little hazy. I know that PKCS are just standards.
PKCS#12 - These are your .pfx or .p12 files, which can be used to store your X.509 certs with the corresponding private key (very simplistic definition). My guess, and please correct me if I'm wrong, is that these are typically created be a server which wants to setup HTTPS. Can use different algorithms, like RSA which is also mentioned in PGP.
PKCS#7 - Subsequently CMS, typically used for generating and verifying digital signatures. Here is where I'm finding some conflicting information. I understand digital signatures, calculate the hash encrypt with the private key so you can verify, with the public key, that the message was not tampered with and that it came from the correct sender. Before I get to the main question relating to auth, I see that PKCS#7 can use AES, which is a symmetric key algorithm. Does this make sense, and if so is this common or how would that work?
Now main questions sorry if that was long winded.

I was told to download a PFX file in order to authenticate with an
API, similar to this question. Question on this, and related to
my next question on PKCS7, is how does that authentication work? I'm
getting the private key and cert in the form of a .pfx file from
the server, does that mean that the server is just self signing this
and this is essentially mutual TLS using a self signed cert? If not,
we then just be using TLS (so encrypted with the servers public key)
with the message content being our payload signed with our private
key?
Similar for PKCS7. I completely understand how we verify the
signature with the public key. How how do we handle the
authentication if we are sending data across to some API (typically
speaking)? Because technically once we have something that we have a digital signature,
really anyone anywhere can send this, so how would we know it is being sent by a particular
client or do we not care?

Sorry for the long post and hopefully you can clear some of this up for me.


texts: How should one create an ephemeral Diffie-Hellman private key?

texts:
When picking an ephemeral Diffie-Hellman private key (little a or little b), can I reasonably just pick 32 random bytes? I am specifically interested in use within SRPv6.

RFC5054 says that these ephemeral keys are "a random number that SHOULD be at least 256 bits in length."

RFC2631 says

  X9.42 requires that requires that the private key x be in the interval
  [2, (q - 2)].  x should be randomly generated in this interval.

(where q is (N-1)/2.)

Goals and concerns

It would be nice to just get a bunch of random bytes and make those into a big integer than to have to uniformly pick a big integer within a specific range.

Question updates following comments

When rfc2631 was first published (1999) DH groups were very small my todays (2017) standards. I am using the 4096-bit group from Appendix A of rfc5054, which means that q is a 4095-bit number. So if I shorten the range to a whole number of bytes, I would need to get 511 random bytes (4088 bits). That is an enormous amount of entropy to be asking.

As noted in a comment, picking a number uniformly in a range (that isn't a whole number of bytes) means addressing the modulo bias. I would much prefer to not try to deal with the modulo bias and so just pick a whole number of bytes.

Related questions (and answers)

My question is related to – but distinct from –  Diffie-Hellman secret key choices, which is asking about some very specific values of generated keys.


texts: Decrypting two XORed compressed messages?

texts:
If through a previous attack, cipher misuse or two time pad etc. I receive $c=m_1 \oplus m_2$. Where $m_1$ and $m_2$ are compressed messages, for instance GZIPped English text documents. Can we recover something significant about the messages?

Obviously if we can guess two prefixes we can verify. Can we do more? Can something practical be done about the end if we fail to decipher the beginning? or even don't have the start of the message.

Since the messages are compressed I don't know of commom substrings except in the header nor do I know how to validate if a short fragment in the middle is plausible.


texts: What is the difference between a Vigenère cipher and a one time pad cipher?

texts:
I'm doing a decryption competition at a nearby college.  We are allowed one cheat sheet so I'm trying to make one.  I realized that the Vigenère cipher was very similar to the one time pad and wanted to make sure that I know the difference.

As I understand it, the only difference is that a one time pad has a key that is as long as the message. The Vigenère cipher can use a key that is shorter than the message, so you repeat the key till the end of the message.

Is above description correct?


texts: The One-Time-Password (OTP) topic became quite popular in the recent years. But unlike the well-known HOTP and TOTP standards I haven't heard about any applications/systems implementing and using the S/KEY standard. Are there any?


texts: Would adding more rounds to AES increase security?

texts:
As the title states, would increasing the rounds by doubling them to Bruce Schneiers recommendation of 16, 20, and 28 increase security? And how much?

As a bit more, would increasing rounds, keys, blocksize, or almost everything increase security?


texts:
I want to design a secure data container that can be used to transfer encrypted data over a public network that can defeat common attacks. Data is already encrypted before entering this container so that is out of scope. The container need to store some detail about the cipher used so that it can be properly decrypted when arrived at the other end.

My basic idea is to use chunks of data, with headers seperated from actual data, containing:

CHNK chunk: chunk list chunk, always the first chunk.
DATA chunk: encrypted data, as is or optionally compressed (after encryption).
SIGN chunk: Signature of the data chunk, either a digital signature or a MAC.
INIT chunk: (Optional) IV of the cipher used, optionally encrypted with the asymmetric algorithm used.
ISGN chunk: (Optional) Signature of (possibly encrypted) IV.
SKEY chunk: (Optional) Encrypted session key, if the main algorithm is asymmetrical.
KSGN chunk: (Optional) Signature of encrypted session key.
INFO chunk: (Optional) Comments that is not encrypted or verified.

File structure: (Using C structure notation, all multi-byte numbers is stored in network byte order)

struct chunk_s
{
    uint8_t  magic[4]; // Chunk FourCC header.
    uint32_t flags;    // Chunk flags, including information of the algorithm.
    uint64_t offset;   // Offset of the chunk from head of file.
    uint64_t size;     // Size of the chunk.
}

EDIT:

To resolve some issues raised in comments, I will say again that the signature chunks can be either a signature or a MAC, also you can apply both a signature and a MAC by using two (or more, if different algorithms are used) SIGN, KSGN, ISGN,HSGNorSSGN` chunks carrying different flags. Algorithm is identified by the flags field.

HSGN chunk: signature of header/chunk list.
RSGN chunk: "signature of randomness", essentially a chunk of nonce that is counted when calculating SSGN chunk
SSGN chunk: signature of all other types of signature chunks concatenated together in the exact order as found in the chunk list. Usually the last chunk.


texts:
I am currently analysing a client-server application which apparently uses RC4. I've got the secret key and nonce and I was very surprised about the approach they encrypted the packets.

Since I am no cryptography expert I will explain what I did so that it works.

I created a string with the full key (nonce + secret) and I append all the unencrypted bytes without clearing it at any time
I RC4 the whole string (which obviously grows over time)
I slice the resulting string so that all old bytes will be cut and only my "new bytes" are left

I can't imagine the server side maintains the whole byte history for every connected client, hence I wonder if it's some sort of RC4 algorithm / modification or if this is a custom implementation


texts: How to convert a set of sequential integers into a set of unique random numbers?

texts:
I have a set of sequential and non-duplicate integers which I would like to convert into a set of non-duplicate random integers.

What I want to achieve is this  - I have a list of sequential numbers like below

[1, 2, 3, 4, 5, 6, 7, 8, 9]

This list is going to be quite big in reality e.g. 100 million

I want to shuffle this list multiple times in order to rearrange the numbers in the list. Each shuffle should give me a new sequence in such a way that, if I pick a number at a particular position in the list after each shuffle, I should never get a duplicate.

For example, if the above list is shuffled three times, I get the following three sequences after each shuffle

shuffle 1 --> [9, 3, 4, 1, 7, 2, 6, 5, 8]
shuffle 2 --> [8, 2, 7, 5, 4, 6, 3, 9, 1]
shuffle 3 --> [1, 9, 6, 7, 5, 3, 4, 8, 2]

In the above lists, if you pick a number at any position, say 2,  from all the sets, you never get any duplicates. You will get a duplicate if you pick position 2 from the first sequence and position 5 from the third set and this is fine.

For some reason, I feel that there should be a cryptographic function for this kind of shuffling to which I can pass my input sequence and I get a shuffled sequence back as described above. Is there any? I have looked at LFSR but just not sure if that solution works in this case.


texts:
I am currently implementing NTRU, keeping its homomorphic properties. I want to implement rerandomization like this:

Encryption: $e = pr * h + m \pmod q$
Rerandomization: $e = e + pr \pmod q$ (using a new random $r$)
Decryption is as described in the original NTRU paper.

The first few rerandomizations work just fine, but after some iterations I am not able to decrypt it anymore. What am I missing in my formula?


texts: Adaptive vs. Static security model in ABE

texts:
From Lewko, I understand the difference between an adaptive and selective model:

Adaptive model: the attacker can adaptively query the challenger for private keys.
Selective model: the attacker has to declare the challenge message BEFORE he can see the public parameters setup.

Now comes to Rouselakis with static model:

  All queries done by the attacker are sent to the challenger immediately after seeing the public parameters.

This is what I understand: After seeing the public parameters, the attacker sends a batch of requests to the challenger, and the challenger replies a batch of responses.

Q1: The word "immediately" confuses me. Why immediately after seeing the public parameters?

Q2: How "weaker" is static model than the adaptive model? Can anyone give an example that the attacker can break this scheme by sending "adaptive" requests to the challenger (but not all requests in one patch)?


texts: Does the Balloon hashing paper deprecate Argon2?

texts:
Does the recent Balloon hashing paper and the included attack on Argon2 effectively negate the result of the Password Hashing Competition? On one hand it seems that only a constant-factor improvement has been achieved, which is rarely critical in cryptography. On the other hand, the entire point of password hashing is to increase the constant factors of brute-force search.

I'm building a new authentication service at the time of this writing; should one use Argon2 or Balloon hashing in new development given this result? (I love the simplicity of Balloon hashing and it comes with a proof, but it hasn't been "selected as a standard").


texts: How should one refer to the smallest remainders generated by a modulus within DH or DLP?

texts:
It's my understanding that the integer base and exponents chosen to create the initial public keys in DH are from the remainders of a modulus.

For example, if the value of the modulus is $N=11$, a set of remainders "produced" is  {0,1,2,3,4,5,6,7,8,9,10}, however, I could also refer to the remainders of $N$ as 11,12,13,14,15,16,17,18,19,20,21.

Is there a way to differentiate by name the remainders {0,1,2,3,4,5,6,7,8,9,10}?

For example, is it accurate to refer to {0,1,2,3,4,5,6,7,8,9,10} as the canonical remainders of $\pmod N$? If yes, then can I refer to a particular base used as the canonical base and the exponent used the canonical exponent? Or is there a different terminology for these elements?


texts: Is authenticated encryption unnecessary if the message is digitally signed?

texts: Normally, it is necessary to use authenticated encryption if the message may be tampered with.  Can the authentecation be omitted if the message has been otherwise authenticated?


texts: why are both ipad and opad required for HMAC?

texts: I was reading about HMAC and why it is crucial to avoid security issues with normal prepending / appending the secret k to a message (issues due to merkel damagard construction). I am not familiar with the math and the detailed proof presented in the paper, but i was wondering why both ipad and opad are required. what if we use only one ? how will an attacker exploit that ?


texts:
What is the conceptual difference between the definition of correctness and completeness in verifiable cryptographic protocols? They justify that if a statement is correct then the verification should always successfully verifies. Is their any difference in the definitions? Or the one can substitute correctly the other?

It seems like authors prefer the term correctness for verifiable computations and the term completeness for zero-knowledge proofs


texts: What are methods of hash classification by finding patterns?

texts:
I have a long set of hashes (long hashes, long set) generated with the same algorithm. And for each hash I know that it belongs to one of two groups.

Are there any methods of hash analysis, that allow to determine with some probability which group (any) given hash belongs to?

update:

A simple example: I have a long set of 64 bit numbers. Some of them are less than 2^40. And these belong to group A. All the rest belong to group B.
I calculate SHA of each. Then I analyse all SHAs with a magic algorithm trying to find a rule determining the group from given SHA with maximum possible accuracy. From other point of view a magic algorithm measures hash efficiency in some way. I do not know how to start with such task, and whether there are any known algorithms performing similar tasks.


texts: I'm trying to understand (to reproduce in practice) how does blinded tokens work. Currently i'm lacking examples. According to Wiki the blinded signature protocol is the same as ordinary signature protocol. So maybe it is possible to reproduce it with the help of openssl? I want to reproduce by hand all the steps required to sign


texts: I am reading about Yao's and GMW protocols and was wondering if there is any perfectly secure MPC protocol in the semi-honest setting, where the underlying circuit is a Boolean circuit (eg. n=3 and t=1)?


texts: ECDSA signature generation and verification latency

texts:
I am performing some measurements of P256 ecdsa signature generation and verification latency and I was expecting that the signature verification will be faster than the signature generation, but is was not the case.
what makes the signature generation faster ? what is the most computationally expensive operation in signature verification ?


texts: Integer factorization based password authentication

texts:
After looking at this security issue at DjangoProject, I started to think in a password-based authentication that places the burden of PBKDF2 (or whatever is the hashing function) on the client. So I came up with the following scheme:

When the user types the password, the client software (browser or whatever) hashes the password to form a seed to use in a pseudo-random generator. Then this pseudo-random generator is used to build two big primes $P_1$ and $P_2$ in a deterministic way. This two primes are the authentication token, sent encrypted through the wire (like the password is sent to websites nowdays). The server side just keeps stored in the database the product of $P_1$ and $P_2$, so — to verify the user — all the server has to do is to multiply $P_1$ and $P_2$ and see if it matches the stored product.

So, what do you think of this method? Is it secure? How big must $P_1$ and $P_2$ be  for this to work? And in the prime generation process, would be better to use some algorithm like Mersenne-Twister ( with huge period size), or Rabbit (which is cryptographically secure), or doesn't it matter?

I think the hashing pass to get the seed must use something like PBKDF2, to make it hard to brute-force attack (like it is today, but it is done on client side). The drawback I see is that rainbow tables with the most common passwords could be built for easy look-up of the stored products. But this problem is easy to circumvent, by using the user name plus the website host (or some website-specific token) to salt the password hashing.


texts: RSA plaintext repetition attack, (same plaintext, different ciphertext)

texts:
Billy wants to send a message to Bob. He generates secure primes p and q for each time he sends a message. However, he accidentally sends the same message multiple times. Is Billy's message still safe?
More formally, I know that e=3 and that the plaintext remains the same for more than 1 message, but the value of n (and subsequently the ciphertext, c) changes.
e=3
n=pq
c=123
plaintext=my-cool-mesage

e=3
n=p'q'
c=456
plaintext=my-cool-mesage

If an attacker has access to the e, n, and c for each message, can they recover the plaintext with the fact that the plaintext is shared, even when n changes?


texts: Can non-repudiation be ensured without public-key cryptography?

texts:
Message authentication is ensured by using HMAC, which can be thought of as a symmetric-key construction.

Source authentication in multicast communications can be guaranteed using TESLA, which is again based on symmetric-key principles (although it basically works because of asymmetries in time).

However, neither HMAC nor TESLA ensure non-repudiation.

Is this a structural limitation of symmetric-key cryptography? Or is there some construct that ensures non-repudiation without using public/private keys?


texts: AES CBC in need of multiple IV's, possible to avoid creating duplicate iv's by using resulting cipher text 16 bytes as next iv?

texts:
I saw a little close to these questions but not exactly.

Encryption method AES-256-Rijndael-CBC:

if we have multiple cipher chunks that look like this:
{iv}{cipheredchunk}{chiphered chunk}{chiphered chunk}....

I earlier got noted that we should never use the same IV for other chunks since chunks could be identical, so we need something like this:

{IV+cipheredchunk}{IV+chiphered chunk}{IV+chiphered chunk}...

My question is, is it okay to avoid adding a bunch of 16 bytes long random IV for every chunk, maybe we could use one fully random IV for the first chunk, and for next chunk use the first 16bytes of that chunk as iv for next block?

Do we keep the safety of the encryption?

Edit:

Every "Ciphered Chunk" is a completly finished encrypted message in AES256 CBC.
So if we for example have the whole plaintext message to encrypt of "abcdefghijk" and we say that every chunk is 3 letters/bytes then we do:

AES256CBC encryption on "abc" -> ciphered text("Ciphered chunk")
AES256CBC encryption on "def" -> ciphered text("Ciphered chunk")
AES256CBC encryption on "ghi" -> ciphered text("Ciphered chunk")
AES256CBC encryption on "jk" -> ciphered text("Ciphered chunk")

The reason i am doing this instead of ciphering the whole plaintext at once is since i am dealing with incredibly large files of many GB which no program or computer can handle at once.

So im trying to cipher small parts of the file in AES256 CBC mode and basically append them next to each other :)


texts: Decoding base64 encoded message with a key

texts:
I am pentesting a database that where I found data which was base64 encoded. I tried the usual method of decoding base64, which didn't work.

Later, I found in database a field called base64_custom_key. How do I decrypt a base64 encoded message with a key?

For eg.
The key looks like gP9jOzA75VyIW6FRuHZimQcLB1rCTKpGN8hdEXw0eY3kMx+/JDUntsob4a2qfSv and the value generated looks like ucaUCo4NmA88Tws8BoQsKAXdBcDn


texts: Practical BCrypt plus XOR encryption for small messages

texts:
This is a practical solution available and potentially useful to everyone, so please give some leeway not banning this question. Details are at the end, but here is the question:

How secure is the following encryption approach?

In few words, it uses BCrypt to hash passwords. BCrypt is then used repeatedly on the result of prior hashing, and all the hashes are concatenated to make a Key as long as the Message itself. The encryption is a simple Key XOR Message. Details are below:

Note. BCrypt salt is hard coded and is removed from the resulting hash, when applying BCrypt function.

Encryption

  Message = Any Ascii128 text
  Pass1, Pass2, Pass3, Pass4, Pass5 = Ascii128 based 5 password fields
  Password = Pass1 XOR Pass2 XOR Pass3 XOR Pass4 XOR Pass5
  Checksum = {

  ShortMessage = Message
  Repeat while ShortMessage is longer than 50 chars,

ShortMessage is cut in half, and the halves XOR to get new ShortMessage

  ChecksumBase = fromBase64toAscii128(BCrypt(ShortMessage XOR Password))
  Checksum = ChecksumBase.substring(1 to 4)}

  Key = {

  LongKey = BCrypt(Password + Checksum)
  CurrentKey = LongKey + Checksum
  Repeat while LongKey.length < Message.length :

CurrentKey = BCrypt(CurrentKey)
LongKey = CurrentKey + LongKey

  Key = fromBase64toAscii128(LongKey)
  }

  SecureCode = Checksum + (Message XOR Key)
  SafeMessage = fromAscii128toBase32(SecureCode)

Decryption

  SecureCode = fromBase32toAscii128(SafeMessage)
  CheckSum = SecureCode.substring(1 to 4)
  Password = see in Encryption
  Key = see in Encryption
  Message = SecureCode.substring(from 5) XOR Key
  CalculatedCheckSum = see in Encryption
  Integrity check = recovered CheckSum must match CalculatedCheckSum

Please, rate the safety of the approach on a scale from "kids safe" to "unbreakable", as quite a few people use the program, and want to know how secret their secrets are.

There is a link from the project's page to this question, so your answers will be a validation of the project for better or for worse.

The program can be run here. It is on GitHub and cannot be maliciously altered without a public record of the change. (There are no plans for change as this would compromise current user base).

If someone would care to take a look at the JavaScript, to ensure it does what is declared and put a comment in here, this would be awesome.


texts: What are the implications of XORing ciphertext with plaintext?

texts:
I was intrigued by this question: Does adding complexity mean a more secure cipher?
And it led me to wonder: What are the implications (if any) of XORing a ciphertext with the original plaintext message? So:

$$C=(E_k(m)\oplus m)$$

My first impression was: "That sounds like a bad idea.", but is it necessarily? Seems like something similar is being used for Propagating Cipher Block Chaining.

  "In PCBC mode, each block of plaintext is XORed with both the previous plaintext block and the previous ciphertext block before being encrypted."


texts:
Our application requires some 'mild' form of 'proof of origin' for the tokens we issue (~200 bytes), however, the value of each is trivial.
The requirement is to provide 'tamper resistance' rather than 'unforgeable', to not bloat the token size, and to use commonly available 'standard' libraries and tools.

In the token, we include a hash of the request we received, and I understand we can crop this down to the last n (e.g. 48) bits easily enough, and do the same with the token hash/digest before signing.

Is something similar possible with the signature, or do we need to just generate the smallest key and a tiny digest to get the output as small as possible?

I've been mucking about with openssl rsautl - is this as good as any other given our requirements as above?  The signatures are coming out at ~24 bytes, I'd like to reduce that a bit further if possible.

EDIT TO ADD

For us, the ability to forge a single signature within a few minutes is perfectly fine, sub-minute is getting problematic.  The ability to derive our private key, and subsequently bulk-produce counterfeit signatures with negligible time/energy cost is the primary risk.

With the advice of those below I've been looking at ECDSA and the secp112r1 OpenSSL built-in curve, assuming that is better than a 256bit RSA primary key.


texts:
do you know any methods for choosing specific position in text for a key?

Background:
Lets suppose, that I want to encode message to friend: Text1 (not too long - max 1000 chars).
I have made publicly available string of 1000 random characters before (RandomText).
Now I want to encode my Text1 in this way:

1) Take part of message (e.g. 10 characters)
2) select key from RandomText (at specified position)
3) encode (it does not matter what is the algorithm)
4) process another part of message with next key.

After encoding I have 100 parts encoded with 100 keys.

My question is - are there any known methods (e.g. ever used in history) for selecting specified positions in point 2)?

e.g. the simplest would be:

nextKeyPosition = previousKeyPosition + someConstant

or

nextKeyPosition = previousKeyPosition + someConstant + someFunction(previousEncodedText)

or anything else.


texts: Montgomery Powering Ladder and Side Channel Attacks: Is it practically (im-)possible to analyze where intermediate values are stored?

texts:
The Montgomery Powering Ladder performs an exponentiation with the operations square and multiply (called double and add in the case of elliptic curves). To my knowledge the order and kind of operations involved are independent from the exponent, which prevents side channel attacks if the exponent is a secret key.

But of course the computation does depend on the exponent: Each bit of the exponent decides where intermediate results are stored. More concretely, the exponent is processed bit by bit and in each step, two intermediate values, say R and S, are updated. If the exponent bit is zero then one of the values, say R, is overwritten with the product of R and S and S is squared. If * denotes the underlying group operation then this can be written as

R <- R*S
S <- S*S

If the exponent bit is one then it is the other way round:

S <- R*S
R <- R*R

So if one could determine which value is squared then this would reveal the respective exponent bit. I guess that this is not possible in practice since otherwise there would have been exploits.

Could someone explain to me why this is difficult in practice? I am an absolute beginner in embedded devices, microcontrollers etc. I am particularly interested in the case where the Montgomery powering is done on an embedded device (not a particular one).


texts: AES CBC: Use hash of key as IV when every key is unique?

texts:
I have an app that uses a different random key for every file that is being encrypted.

Am I correct in assuming that this means that I can safely use a hash of the random key as the IV, because that would also lead to a unique IV?

If possible, I would prefer to not store the IV along with the file for performance and storage reasons. OTOH, I obviously don't want to compromise on security...

Thanks for your advice


texts:
I know next to nothing about cryptography, which is bad because I'm a programmer. I was exploring some code the other day and the encryption part of it seemed a little strange to me. I'd like the name/terminology/links to this algorithm/concept so I can learn more about it, and I'd also like to know if it's secure or a waste of processing. Also please bear with me, I don't know any of your terminology u.u

The code included some stuff that sounds pretty good: it uses CBC with AES/Rijndael (using 256 bit block size) with null byte padding (the data is supposed to end with a certain character so null bytes works). The IV is randomly generated with each encryption and is then prepended to the encrypted data (second question: does this practice have a name?). But then as a wrapper around that it has another layer of "encryption"? - I'll try to explain it the best I can:

First, the key that was used in the AES/Rijndael is passed through a hash function. I'll call this the key hash? This same value is used in both encrypting and decrypting. Then the encrypted data (from the AES CBC, and with the IV in front) is broken into chunks the same length of the key hash (blocks?). Each byte of the key hash is added to the encrypted byte, and then modulus-ed(?) (if > 255 then subtract 255). Currently the hash function used is MD5, but I'd also like to know about this in a more general sense too.

Is this whole method secure? What is it called? Is it a waste of processing? Can it be done more efficiently/better? Why did the developer choose to do it like this? Etc... So many questions!

Not important but: The developer then proceeds to store/send the encrpyted data over the network as... doubly base64 encoded data, and then inside xml. e.g. xml(base64(base64(encrypted data)))... Gross!!! And the original data is so verbose and redundant too.


texts: Is there a developer's resource that ties encryption methods and strengths to the appropriate usage scenarios?

texts:
I'm not looking necessarily for implementations in any language (although it would help to list those resources as well), but what I am most interested in is a discussion of what advantages and disadvantages certain encryption methods have when applied to a given scenario. Just for a frame of reference:

I want a user to enter a username/password that will be stored in a database.
I want to encrypt a PDF file and send it to a friend and have her decrypt it.
I need to encrypt a small amount of plain text and have someone else decrypt it.

I'm sure there are better examples, and there is sure to be some crossover, but it seems like much of the time spent on encryption is deciding what is the best method given the variables or scenario involved. Is it a one way hash? Do others need to decrypt it? Am I the only one to decrypt it? Is it binary or text? Are there file size limits? Is it stored, or sent over a network?


texts: Are SHA-256 and SHA-512 collision resistant?

texts:
This is my first post on this forum, apologies if this post is naive. I want to learn cryptography and I want to start with this question.
Context: Designing a TinyUrl system. The user inputs a lengthy URL and the system computes the hash and encodes it binary64 and sends it back to the user.
From what I understood so far (from this forum and also from Wikipedia) that SHA-2 algorithms are not collision-free. If these functions are indeed not collision-free, how to make them collision-free?  There are resources on the internet that recommend adding jitter, for example, a unique string at the beginning of the URL, a viable solution in software systems design. This not only makes the different URLs produce different hashes, but it also makes the same URL produces 2 different hashes on 2 different tries (presumably for 2 different users). In the reverse lookup, the system can ignore the prefix and redirect the user to the original URL using HTTP 302. However, this adds its own complexity to the system that is generating/using unique prefixes across different servers of a distributed system.
Question-1: What are the chances that 2 different strings/URLs produce the same hash when used SHA-256 or SHA-512?
Question-2: Assuming that the system saves 30billion URLs their hashes in database, what is a recommended hashing function, if not SHA-2? Please note that a requirement of the system is it should be highly available, meaning: hash computation should not take very long.
Appreciate any help. Thanks in advance!
PS: Happy to get started with cryptography.


texts:
The paper "On the group generated by the round functions of translation based ciphers over arbitrary finite fields" states:

  Definition 3.3. A block cipher $C =  \{ \tau_k | k ∈ K \}$ over $F_q$ is called translation based (tb) if:

  each $\tau_k$ is the composition of $l$ round functions $\tau_{k,h}$ , for $k ∈ K$, and $h = 1, . . . , l$,
  where in turn each round function  $\tau_{k,h}$ can be written as a composition $\gamma_h\lambda_h\sigma_{φ(k,h)}$ of three permutations of $V$ , where:

  $\gamma_h$ is a bricklayer transformation not depending on $k$ and $0\gamma_h = 0$
  $\lambda_h$ is a linear permutation not depending on $k$,
  $φ : K × \{1, . . ., l\}→ V$ is the key scheduling function, so that $φ (k, h)$ is the $h$-th round key,  given the master key $k$;

  for at least one round index $h_0$ we have that

  $\lambda_{h_0}$ is a proper mixing layer, and
  the map $K → V$ given by $k → φ (k, h_0)$ is surjective, that is, every element of $V$ occurs as an $h_0$-th round key

How do I check if this map is surjective? Is AES a translation based block cipher?


texts: Which sub operation is more expensive in the AES encryption process?

texts:
In the AES encryption process, there are various sub-operations, like SubByte, MixColumns, ARK etc. My question is which of these operations is more expensive?  In a video lecture by Dan Boneh, it is mentioned that the lookup table implementation of AES is faster than the implementation where the MixColumns function is performed using finite field multiplication.
I do not find any information on how much faster it is? Also, is there any relation between the individual sub-operations in terms of individual CPU time?


texts: Can ECDSA key pairs be added up or multiplied?

texts:
I have been given a public key ($y_1=x_1G$), but I don't yet know the private key ($x_1$). At a later time, I will get $x_1$ if some conditions are met.

Question:

Let's say I generate a new key pair $( y_2, x_2)$, both of which I will know.

Is it possible to add up these key pairs?

$ y =  y_1 + x_2G$
$ x = x_1+x_2 $

Let's say (before I have $ x_1 $) I encrypt a text with $y$. And let's say I get $x_1$ at a later date. Can I decrypt my text using $x$ (by adding up the private keys)?

Let's use ECDSA key pairs. Sorry if my question is somehow deficient, but I just started to study cryptography. You would help me a lot by clarifying this question. Best, Stan


texts: Okay to use OpenSSL to encrypt then sign a message?

texts:
I am planning on encrypting a message then signing the message so the recipient can authenticate the source. Reading this article has me concerned that I'm doing something wrong.

My current plan is to use OpenSSL to do the following:

Create a random key
Use key to encrypt message with a block cypher
Encrypt key with recipient's public RSA key
tar the encrypted message and encrypted key
sign the encrypted package using openssl dgst
tar the signature and encrypted package for delivery

Is there anything wrong with this approach?

This is being used for transferring firmware for an embedded device. The firmware includes an entire filesystem, including a private key. It needs to be encrypted so the private key is not exposed, and it needs to be authenticated so that a third party cannot install their own firmware and have access to the device (and the private key within).


texts:
Carter-Wegman MAC variants (VMAC, UMAC etc) are known to be very fast and efficient when compared to MAC algorithms that are based on block ciphers and compression functions (like HMAC, CMAC etc).

However, Carter-Wegman MAC variants are not very popular on the internet like HMAC. Why is this so? Do Carter-Wegman MAC variants have some disadvantage that prevents them from being widespread?


texts: Where is the mistake in my RSA by-hand calculation?

texts:
Like several previous askers, I seem to have made a mistake in my RSA calculation, but despite going back over it three times, I cannot spot it.

I picked 1000003 and 6000011 as my primes, p and q.

n = 1000003 * 6000011 = 6000029000033
z = φ(n) = (1000003 - 1) * (6000011 - 1) = 6000022000020
e = 17 (arbitrary pick of small integer that's coprime to z)

Public key is (e, n) = (17, 6000029000033)

Found d by solving (17 * e) mod z = (17 * d) % 6000022000020
d = 857146000003

d was calculated with an online multiplicative inverse calculator. I suspect this is where the error is, but I've redone it several times with different calculators to no avail.

So then I encrypted the number 6:

encryptedMessage = (message)^e mod n
encryptedMessage = (6)^17 mod 6000029000033
encryptedMessage = 4926601444670

Decryption is where I realized something must be wrong, because:

message = (encryptedMessage)^d mod n
message = 4926601444670 ^ 857146000003 mod 6000029000033

Except obviously that exponential operation is too huge to be done. I can't calculate it anywhere. It crashed my interpreter when I put it into python.

What am I doing wrong here?? :(

Or, perhaps, am I doing it right, and it's just that there's a necessary efficient method for this calculation which I'm not aware of?


texts:
I currently need to encrypt large files (video, over 6 Gbytes) for our customers.
To ensure authenticity and integrity, we chose HMAC-256 as we already use it in our internal messaging system.

But working in embedded systems, we are limitted by the memory.
If the message is the whole data file, we could not stored 6Gb in memory to compute the HMAC.

Is there a dedicated protocol that breaks up the message into smaller blocks and create iterative HMAC ? Or any other way to achieve it ?


texts: Interactive ECDHE Authentication With Numeric Code

texts:
Trying to simplify my question, keeping only core concepts.

Proposed solution:

Both user devices generates ECDHE key pairs. Send pub keys to each other. Generate shared secret.
Device that requests secrets – presents dialog with the 6 digit code. 6 digit code is just first 6 bytes of SHA-512(shared_secret||A_identity||B_identity) and mod 10 of each byte.
Device that expected to share secrets asks user to enter 6 digit code. And if code entered is correct (no man-in-the-middle + explicit user approve on action) – uses KDF on shared secret to generate transfer key and sends all data to other device.

As it's ephemeral keys and there is no ability to brute-force keys with the same fingerprint easily from first try - it is seems to be ok to use just 6 digit fingerprint. Server has no ability to intercept data or to introduce himself as legitimate device.

I'm not a security or crypto expert. Obviously I must not re-invent secure communication protocols. That's why I'm here to ask.

What are drawbacks of solution I propose? Are there any well known protocols for that case ?


texts: Algorithm for sharing secret information with redundant keys

texts:
I have an information that I would like to encrypt and give it to someone else. I would like to encrypt it using N separate passwords (say 5) and give each password to some other persons. However the tricky part is that I would like to have any M of them (M<=N, say M=4) to be able to get together and decipher the message. Is that possible using some sort of conventional free software?

My use case is to write a secret message, give it to one of my friends and then distribute passwords to others. However if one were to lose their part, the entire message would be lost. That is why I would like to have a redundancy. If you have any other idea how to solve this, I am open to it as well.

Thank you.


texts: Understanding Diffie-Hellman - Choosing a bad g

texts:
I am taking a class on Cryptology, and I'm having a hard time understanding the potential pitfalls of Diffie-Hellman. Specifically, the professor gave the following problem:

  Alice and Bob want to use Diffie-Hellman for key agreement and choose
  p = 982734982635928741927391824619283719654192837198273923771,
  however, they do not know how to calculate a relative prime, and hire
  Evan (Eve in disguise) to generate one for them. Evan gives them g =
  584451952932889263219289637911613296416146180021897568955.

  Explain what Evan did, and how this makes it easy for him to find the
  secret key that Alice and Bob agreed to, and find that secret key.

I understand that the value of choosing a g that has a large sub group of possible keys (i.e. you wouldn't want to choose g = 1, because then all keys would be = 1, no matter the other numbers) but I'm not understanding how that would impact this case with such a large g. Could anybody explain how I'd go about this question?


texts: Can the key-complement property of DES be used against 3DES?

texts:
The comments in this recent question about the security of 3DES made me wonder if the key complement property of DES (which reduces its security by ~1 bit) can be used in the meet-in-the-middle attack on 3DES.

Can the complexity of the attack be reduced by 1-2 bits by making use of the complement property to rule out more keys than are being directly tested?

Sure, the difference between 112 and 110 bits probably does not matter in practice.


texts: Common modulus attack with not coprime exponents

texts:
lets suppose we have the public keys $(n,e_1)$ and $(n,e_2)$, such that $\gcd(e_1,e_2)=d>1$, and the same message encrypted with these two keys.

I'm trying to see if common modulus attack on RSA can be adapted to these problem where $e_1$ and $e_2$ are not coprime, but I always get stuck at some point where I should calculate a discrete logarithm, which is obviouslly not viable in an attack to a cryptosystem.

Any ideas about if it is possible this adaption?


texts: Public key of a split key without calculating private key

texts:
I am searching for a secret splitting scheme where the private key doesn't exist, since each party chooses their own secrets. The other parties should however still be able to calculate the public key.

For example everyone chooses their own plane and the intersection that - when calculated - would become the secret. We need the public key of that secret.

Basically such a scheme would amount to secret splitting without a dealer. It could use but some kind of algorithm that uses homomorphism. Such a scheme could allow the public key to be calculated.

It seems possible. It would be similar to an algorithm that allows three people to calculate the average salary without disclosing their individual salary.

If such an algorithm cannot exist then a explanation showing that it is impossible would be great.


texts: Whitebox AES: why not steal the whole whitebox?

texts:
If I understand correctly, Whitebox AES is a way of transforming decryption code to make impossible to recover the decryption key, even if you have access to the code.
But what's stopping someone from just separating the entire whitebox decryption function from your program and using it inside their program? They won't have the key, but they'll be able to decrypt any data and use it for whatever they want.


texts: Need help with PKCS#12 3 key triple des key expansion

texts:
I am trying to decrypt PKCS8-Shrouded Key Bag inside a PKCS#12 pfx file.

The oid for the encrypted data is PbeWithSHAAnd3-KeyTripleDES CBC.

Iteration count and salt has been provided within the pfx file, and I know

the password.

As far as I know, 3Key Triple DES needs 3 × 56 = 168 bits of key.

I am not sure what I need to do exactly to generate a 168 key using pbkdf2.

Do I simply generate a 192bit key using pbkdf2 and divide it into 3 parts and

use them as three seprate keys after having ignored parity bits?


texts: How many additions modulo $2^k$ and multiplications in $\mathbb F_{2^k}$ are needed to resist cryptanalysis?

texts:
Consider a $k$-bit block cipher with $r$ rounds, and key composed of $r$ subkeys $K_i\in\{0,1\}^k-\{0^k\}$ (that is, non-zero $k$-bit bitstrings), for $i\in[0,r)$. Plaintext is $P=S_0\in\{0,1\}^k$, ciphertext is $C=S_r\in\{0,1\}^k$. At round $i$:
$$S_{i+1}=\begin{cases}
S_i+K_i&\text{[addition in group }(\mathbb Z/2^k\mathbb Z,+)\ ]&\text{if }i\bmod 2=0\\S_i\otimes K_i&\text{[multiplication in field }(\mathbb F_{2^k},\oplus,\otimes)\ ]&\text{otherwise}\end{cases}$$
What must be $r$ to resist cryptanalysis? Possible declinations:

Up to what $r$ are we able to exhibit an explicit polynomial-time algorithm (w.r.t. security parameter $k$) that distinguishes the construction from a random permutation with non-vanishing probability, given access to an encryption and decryption oracle?
What should be $r$ for a given $k$ of practical interest (e.g. $k\ge64$ or larger) so that $2^n$ group/field operations are (conjecturally) needed to distinguishing the cipher from a random permutation, assuming say $2^{k/2}$ queries to an encryption and decryption oracle, and random key within the restriction that each subkey is non-zero?

We assimilate a bitstring $B\in\{0,1\}^k$, consisting of $k$ bits $b_i$, to integer $B=\displaystyle\sum_{0\le j<k}b_j\,2^j$ in $[0,2^k)$ of ring $\mathbb Z/2^k\mathbb Z$. We assimilate said $B$ to binary polynomial $B(x)$ of degree less than $k$, so that $B(x)=\displaystyle\sum_{0\le j<k}b_j\,x^j$. Multiplication $\otimes$ in field $\mathbb F_{2^k}$ is polynomial multiplication modulo the primitive (thus irreducible) binary polynomial $R(x)$ of degree $k$ minimizing $R(2)$ when evaluated in $\mathbb Z$ (see Joerg Arndt's list, OEIS A132448).

The initial motivation was this question, which can be solved by a fast 64-bit block cipher that we can build with CLMUL now on many CPUs. That evolved to the study of a minimalist block cipher.


texts:
Consider Shamir's No-Key protocol. What if you substitute the asymmetric operations with XOR, each party using an ephemeral OTP.

It's symmetric, so you could apply the protocol scheme as if it were homomorphic
It's much faster than Shamir's solution using public key crypto

Would this still be a valid and comparably secure protocol as Shamir's No-Key protocol?


texts: Why haven't any SHA-256 collisions been found yet?

texts:
I've been thinking about this for a few days, a SHA-256 algorithm outputs 64 characters which can either be a lowercase letter or a number from 0-9. Which should mean that there are 64^36 distinct SHA-256 results.

How has a collision never been found? If I decide to find the hash for a random input of increasing length I should find a collision eventually, even if it takes years. I imagine this can also be done where the input is a large file and you just change one byte and calculate the hashes until you find a collision. Why hasn't' this happened?


texts: How can I edit or build an app to encrypt data, and build a decryption key?

texts:
I'm curious how I could make an app or add a function to an app that will encrypt the data, then a key that will decrypt it. Specifically, I am wanting to be able to add a "button" or setting on the camera app on my phone that will encrypt the image (I imagine encryption via altering the pixels of the image for cool effects, but that may not be logically efficient), then a setting on my gallery that will do the reverse and decrypt it. My main reasoning is to be able to do really cool transformations to images via algorithms (cause that kind of thing is really fun for me), but as a bonus I'll be able to keep my images more secure. I don't know if this is the place to ask, but I'm interested in cryptography (though I'm familiar with the concept, new to the practice), and I thought here may be good. Thank you in advance for any help you can give.

For added details, I'm looking to do this on an iPhone 7+ and galaxy Note 5 so the encrypt/decrypt can work on both, together or separately. This part isn't entirely necessary, but pertains to the specific case I have.


texts: Is it possible to perfom quadratic residues attack on elgamal cryptosystem?

texts: I understand how this attack work on mental poker, but i am unable to see how can i apply it in Elgamal.


texts: On the probability of a collision in RFO-rCTR

texts:
My slides show that assuming a polynomial number $q(n)$ of blocks have been encrypted by a random function oracle in the context of a CPA-game, the probability of having a collision in the input to the oracle is bounded by $\frac{q(n)^2}{2^{l(n)}}$ (cfr. Katz and Lidell, 2nd edition pages 93-94).

Then I am proposed the following: assuming that in total $e(n)$ messages are encrypted each consisting of at most $s(n)$ blocks then the probability of a collission in the input is bounded by $\frac{e(n)^2s(n)}{2^{l(n)}}$.

Is this a typo? Why are we dropping the square from $s(n)$?

Here you may see the slides I refer to (see slide 18 and 19)


texts: Unpacking the definition of negligible & non-negligible

texts:
There are several threads on this topic including:

How is an epsilon of 1/1000 non-negligible?

How to calculate if probability is negligible or not

(and others)

but I do not fully understand the answers in those threads.

My question is:

I would like to see what the definition of negligible & non-negligible means in an intuitive sense and unpack the definitions and use an example to see how the definitions apply.

The definition I am using is:

$\epsilon$ is a function $\epsilon$: $Z^{+}$ $\rightarrow$ $R^{+}$ and

$\epsilon$ is non-neg: $\exists$d: $\epsilon$($\lambda$) $\geq$ 1/$\lambda^{d}$ inf often ($\epsilon$ $\geq$ 1/polynomials, for many $\lambda$)

$\epsilon$ is neg: $\forall$d, $\lambda \geq \lambda_{d}$: $\epsilon$($\lambda$) $\leq$ 1/$\lambda^{d}$ inf often ($\epsilon$ $\leq$ 1/polynomials, for large $\lambda$)

Several questions:

What do these definitions mean in an "intuitive" sense?
What does $\epsilon$, $\lambda$, d, $\lambda^d$ mean?
How can you use these definitions to show that $\epsilon$:($\lambda$)=1/$2^{\lambda}$ is negligible and $\epsilon$($\lambda$)=1/$\lambda^{1000}$ is non-negligible?

(I know one of these examples is shown in another thread but I do not understand their solution and I want to see what each piece in the definition means in 'english' and then see how the definition is applied to each of these examples to show that they are negligible and non-negligible. I am hoping someone can provide a fresh explanation to the definitions and show how the definitions are applied to these problems and problems in general.)

Thanks!


texts: "open-key model" attacks, why would one be concerned?

texts:
In a paper on a Feistel network, I found the line

  we have made no effort to guard against attacks in the open-key model

and then I found this paper at iarc.org on the subject.  I found only a single reference to this as an actual problem with RC4 and related keys in WEP implementations.  If the open key model is an issue with related keys, why would the authors of a paper relating to a Feistel network make the statement regarding the "open-key model".  Particularly, due to all of the work with Feistel networks and their proven security for a high round counts, I just don't understand why they would need to include this disclaimer.  Is there something that I am missing?


texts: What vulnerabilities would open up if PGP authentication didn't have integrity checking?

texts:
It is my understanding that PGP has both an integrity check and an authentication check. What vulnerabilities would open up if it didn't have that integrity check?

It seems like the authentication check is also basically an integrity check because the authentication would be a signature of the message. So if the message changed, the signature would be off.


texts: Why is synthetic IV (SIV) mode considered deterministic authenticated encryption (DAE)?

texts:
I was just going over my (old) notes from Coursera's Cryptography I course, and I was puzzled by the description of SIV as providing deterministic authenticated encryption (DAE). The general SIV construction shown is to first compute a MAC over the plaintext using a secure PRF, and then to encrypt the plaintext using a secure block cipher in CTR mode using the MAC tag as the IV and an independent key. The IV and the ciphertext are then output.

As far as I can tell, this is essentially an Encrypt-and-MAC scheme, which would seem to me to be open to the same kinds of chosen ciphertext attacks as SSH? Is there some aspect of SIV that excludes such attacks? Or are such attacks excluded by the definition of deterministic ciphertext integrity?

From http://cseweb.ucsd.edu/~mihir/papers/oem.pdf page 17:

  E&M does not provide INT-CTXT. E&M also fails to provide integrity of ciphertexts. This is because there are secure encryption schemes with the property that a ciphertext can be modified without changing its decryption. When such an encryption scheme is used as the base symmetric encryption scheme, an adversary can query the encryption oracle, modify part of the response, and still submit the result to the verification oracle as a valid ciphertext.

Is this ruled out because SIV is only defined over CTR mode and so excludes such encryption schemes?


texts:
Suppose I cascade cipher A and cipher B to encrypt a message. Both ciphers use the same key. I know that theoretically, the security of the setup when used correctly is at least as secure as the most secure. In other works, if cipher A or cipher B is broken, there is still cipher B or cipher A protecting the data. Is it possible under any case for cipher A or B to "reveal" the key, since it's broken? If this happens, then the attacker would know both keys and be able to decrypt the text.
TL;DR: Can a broken cipher ever reveal the key directly?


texts: It seems we can use every identification scheme to sign and verify a message and vice versa. I am right or not? What is difference between an identification scheme and a digital signature scheme?


texts: Hashing passwords with a salt - why use different salt for everyone?

texts:
Given a database where we have usernames and passwords, we want to secure users' passwords by hashing them. We should not use only username and passwords in this hash, as someone having data from other sites that uses the same hashing function can come to the same results and thus know our passwords. If we try hashing the passwords by themselves it would be easy to bruteforce the entire database and guess all the passwords. In normal applications, passwords are hashed with a random salt that is stored along with them to prevent them from being bruteforced easily.

However, we could just use username, password and the same salt for every record in the database. This option would save one data field for each record, while the combination of username and password would be unique for our entire database. Is such a solution just as safe as the traditional password hashing scheme, or are there some security drawbacks to them I am not aware of?


texts: Hiding identifying data while allowing matching?

texts:
I do research with people about their illegal drug use, and for one project I'm doing surveys with them when they visit a needle exchange.  So over time the same people get repeatedly surveyed as they visit the exchange many times over.

In order to link together multiple surveys from the same person across time (because we want to track things like engagement with drug treatment and changes in level of drug use), I ask them to give me some information that they can remember from visit to visit but which would at least moderately limit the ability of someone to identify them from it: the first two letters of their mother's first name, the day of the month on which they were born,and their gender.  E.g. a woman (F) born on [month]/20/[year] whose mother's name is Jane would get the code JA20F.

So every survey gets this code as a unique identifier, and you can link multiple surveys done by the same person without having to record blatantly identifying info like names and dates of birth (or ask a street-based drug user, potentially with mental health problems as well, to remember a unique study ID from visit to visit).  Not perfect from a security point of view, and not unique if you have thousands of people, but when the data is being entered on a single laptop with full disk encryption and all study files are stored encrypted and you have a Federal Certificate of Confidentiality (protects research data on illegal activity against subpoena), and there's only about a thousand people using the service, probably good enough.

But storing that identifier still bothers me.  I'd really like to do something to it at the point of data entry so it can't be 'reversed' back to the potentially identifying day of birth, gender, and first two letters of mother's first name.  My initial thought was to hash the unique identifier before storing it, which again is better than nothing but anyone who knows the format of the unique identifier could easily use a rainbow table approach to unmask it.  As I understand salting, self-salting would mean the hash was different each time for the same individual, so I'd lose the ability to link surveys done by the same person.  And using a single salt would just make the salt the vulnerable piece of data.

Does anyone have any ideas (or well established techniques I'm just ignorant of) for one-way hashing a string which a) is not vulnerable to rainbow tables, but b) produces the same output every time from the same input?


texts: Can a properly implemented ed25519 private key with public underlying data be cracked?

texts:
If the underlying data is public albeit hashed with SHA-512, does that make a difference on the strength of ed25519?  Please quantify the extent.

Can ed25519 be cracked after a certain amount of known signatures?  If so, please quantify the conditions.


texts: where should private and public keys be stored?

texts:
I am kind of confused whether should a newly generated key pair be stored in a keystore or in just a normal plain text file?

From what I read from online source, there are serveral explainations about what the keystore actually store.

some says it stores the certificates only while some says it stores the key pair as well as the digital certificates.

and if the answer is storing in a normal plain text file, won't that be insecure?


texts: what is number of invertible matrix m*m on$ z_n$?

texts: please help me what is number of invertible matrix $m*m$ on Group $\mathbb{z}_n$ ?, assuming we know this number in $\mathbb{Z}_p \quad$ (p is prime) is   $(p^{n}-1)(p^{n}-p) \cdots (p^n-p^{n-1})$


texts: If plaintext is random, how does it affect my choice of encryption algorithm?

texts: I want to encrypt a key file, which is assumed to be truly random (generated with hardware RNG, for instance). Given that there are no patterns in the plaintext, what implications are there for my choice of encryption algorithm? Could I get away with something as trivial as a Vigenere cipher (or XOR equivalent)? Assuming the keyspace is substantially large to prevent brute-force attacks, what other vulnerabilities are there when the plaintext is random?


texts:
This term I have many cryptography courses treating finite fields.
I was wondering if there is any good software that could help doing basic operations in galois fields etc.
I already googled but found nothing appropriate.

What I would need:
A tool/software that can calculate in arbitrary galois fields gf(p^n)

(+,-,*,/,gcd, inverse)

In addition to that I would need a function to generate an irreducible polynomial for a given field. (parameters could get big e.g. 2^100)

I already considered matlab generating a irreducible polynomial for gf(2^103), but computation takes too long.

Do you have any recommendations and do you know any good programs for calculation in finite fields?

Thanks.


texts: Question about OpenSSL testing for FIPS 186-4 and using BN_generate_prime_ex

texts:
I am working on testing my implementation of OpenSSL using the CAVP
186-4 RSA Validation System (RSA2VS).

There are tools under openssl-fips-2.0.16/test and I am working on modifying fips_rsagtest.c to process the 186-4 test vectors the way I need them.

The fips_rsagtest.c program was originally made to take in values for Xp1, Xp2, Xp, Xq1, Xq2, and Xq from an input file and generate the primes p and q.

But the newer tests require I generate the random values Xp1, Xp2, Xp, Xq1, Xq2, and Xq on my own.  Looking at fips_rsagtest.c, it would create the primes p and q using the function RSA_X931_derive_ex().

I looked through these X931 functions and they do not appear to be the same functions OpenSSH calls: RSA_generate_key_ex().

My test lab has informed me that they have validated OpenSSL against 186-4 so I'm wondering if those implementations had custom code in them or if the built-in functionality in the current OpenSSL was able to pass the CAVP 186-4 tests.

That leads me to my 2 questions:

Q1) Does anyone know if it is OK to use these X931 functions for 186-4 testing?

Q2) If they are not, any pointers on how can I get these Xp1, Xp2, Xp, Xq1, Xq2, and Xq values out of the regular RSA_generate_key_ex() function?  It appears to use BN_generate_prime_ex() but there are no obvious variables with the Xp1, Xp2, Xp, Xq1, Xq2, and Xq labels.

Thanks for any insight you can provide!


texts:
So, Alice wants to use the RSA protocol and pays Cindy to generate the two (odd) primes p and w so she can use e=65537 and n=pw as her public key. Alice will then, upon receipt of p and w, privately, find d to use as her private key.

Cindy delivers p and w to Alice where p is prime, but she messes up and delivers a number w to Alice which is composite. This number w is the product of two (distinct) primes. (Assume (p,w)=1.) Alice doesn't realize that w is prime and under this assumption finds d. Therefore publishes her public key (65537,pw).

Amazingly, whenever a message M is sent to Alice using RSA using her public key and Alice uses her d, she always recovers the message M correctly! (Of course we assume that M and pw have no common factors).

How in the world is this possible?? What is the formula??

How do we prove that there is no such w that is 512 bits in size??

Edit: Also, how can we prove that two primes dividing w cannot have the same number of bits (in binary representation)?


texts: Implications of identical round keys in AES (Rijndael)

texts:
When reading up on the Rijndael key schedule, I learned that the master key itself is used as a round key directly before the key schedule generates additional round keys. When a 256-bit key is used, the first half of the key goes to the first AddRoundKey and the second half goes to the second. This means that, if the 256-bit master key is composed of a single 128-bit value repeated twice, the first and second round key will be the same. I assume the cipher is not designed to remain secure under identical round keys, or there wouldn't be the need to use a key schedule.

Example key schedule test vectors with a 256-bit null key show round keys 1 and 2 are identical:

 key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

rk01: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
rk02: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
rk03: 62 63 63 63 62 63 63 63 62 63 63 63 62 63 63 63
rk04: aa fb fb fb aa fb fb fb aa fb fb fb aa fb fb fb
rk05: 6f 6c 6c cf 0d 0f 0f ac 6f 6c 6c cf 0d 0f 0f ac
rk06: 7d 8d 8d 6a d7 76 76 91 7d 8d 8d 6a d7 76 76 91
rk07: 53 54 ed c1 5e 5b e2 6d 31 37 8e a2 3c 38 81 0e
rk08: 96 8a 81 c1 41 fc f7 50 3c 71 7a 3a eb 07 0c ab
rk09: 9e aa 8f 28 c0 f1 6d 45 f1 c6 e3 e7 cd fe 62 e9
rk10: 2b 31 2b df 6a cd dc 8f 56 bc a6 b5 bd bb aa 1e
rk11: 64 06 fd 52 a4 f7 90 17 55 31 73 f0 98 cf 11 19
rk12: 6d bb a9 0b 07 76 75 84 51 ca d3 31 ec 71 79 2f
rk13: e7 b0 e8 9c 43 47 78 8b 16 76 0b 7b 8e b9 1a 62
rk14: 74 ed 0b a1 73 9b 7e 25 22 51 ad 14 ce 20 d4 3b
rk15: 10 f8 0a 17 53 bf 72 9c 45 c9 79 e7 cb 70 63 85

Do two identical round keys cause any security issues in Rjndael?


texts: How exactly does certificate based authentication work?

texts:
I know the concept of key generation, as well as encryption and decryption using public and private keys.

When it comes to authenticating a user by a server, in general there are three types:

password based,
certificate based, and
hybrid (encrypting the symmetric key using asymmetric algorithm).

I am a bit confused how exactly the second type (certificate based) works using nothing but a certificate and I'm a bit unsure about how exactly it works. Can anybody tell me what is being sent from the user's side for getting authentication from the server?

I don’t want reference links from other websites containing elaborate explanations. Just the core of it will do. Generally, how and what is sent from the user so that the server can identify the user? How is certificate based authentication able to replace password based authentication, and how exactly does it work?


texts: Difference with round keys and round constant in AES

texts: I am confused with round keys and round constant in AES. Are they the same? Can someone explain it to me?


texts: Using cryptographically random password as both the password and the salt

texts:
This question is theoretical, but will help with my understanding.

All of my passwords are securely generated using 64 random letters (both uppercase and lowercase) and numbers.

Using the argon2i password hashing algorithm, if I supply this long random password for both the message and the salt, will it still remain reasonably secure. In all cases the salt will be equal to the password being hashed.

My understanding about salts leads me to think, since the password is already sufficiently complex and random, that the salt always being the same exact value as the message/pw doesn't necessarily make the password reasonably discoverable. How does this apply to argon2i?


texts: Why file removal tools offer gost 2 passes and British 3 passes or even gutman 35 passes options? In which case the single pseudo random pass is not enough?


texts: Can you help me understand hash-preserving encryption?

texts:
I have rather simplistic understanding of cryptography, so I have to beg a pardon in advance if the question has internal contradictions.

Imagine data $A$ with a hash $hashA$. This data is encrypted with private key $K$ to get data $E$ and the hash of the encrypted data is $hashE$.

Are there encryption method and hashing method, which will allow to verify, given $hashA$, $hashE$ and $K$, that $hashE$ is indeed a hash of “A encrypted with K”?
How secure could that algorithm be against attempted forgeries, i.e. someone having access to $A$ creating $E$ and $K$, so that $hashA$, $hashE$ and $K$ are correct in sense of $1$, but $E$ is not “A encrypted with K”?

Clearly the identity hash $(hash(x)=x)$ works, but I'm more interested in hashes which are significantly smaller than the original data.


texts:
I have an implementation of the RSA private key operation in a context where I don't have access to an entropy source. I'd like to add blinding to it (both message and exponent), to make it resist some side channel attacks.

(The subsequent padding operation does have access to an entropy source. It's only the exponentiation operation that can't use an RNG.)

I can run a PRNG inside the RSA private operation if I want. My constraint is that rsa_private has to be deterministic: its operation can only depend on its inputs (message and private key).

Is it sensible to do blinding deterministically, i.e. use a PRNG that is seeded by the message and the key? And if so should it be seeded by message+key or key alone? Or does the blinding need to be unpredictable?

I'm interested in the answer for both CRT and straight $m^d$ implementations.


texts: Serpent block cipher : S0 to S7 functions unclear

texts:
I am presently implementing the serpent block cipher in C++ following the specifications. It's important to mention that I'm implementing the cipher in bitslice mode. You'll need the The full submission package of Serpent which contains the specification of the algorithm and the source code in C and Java.

Lets start with the key schedule algorithm at pages 6 and 7 of the paper. You'll see ${k_0 , k_1 , k_2 , k_3} = S3(w_0 , w_1 , w_2 , w_3)$ and the following equalities for k. $S_i$ is a S-Box for $i = 0,\ldots, 7$. Notice that those S-Boxes take 4 32-bit integers as input parameters and return 4 32-bit integers. This confuses me, because on page 3, they write that those S-Boxes take a 4-bit integer as input parameter and return a 4-bit integer.

If someone can help me to understand those S-Boxes, it will be very appreciated. I need to know how to build them by using the ones mentioned at page 21 (A.5).

Also, in the serpentsboxes.h file given in the package, I saw the following code :

/* S0:   3  8 15  1 10  6  5 11 14 13  4  2  7  0  9 12 */

/* depth = 5,7,4,2, Total gates=18 */
#define RND00(a,b,c,d,w,x,y,z) \
{ register unsigned long t02, t03, t05, t06, t07, t08, t09, t11, t12, t13, t14, t15, t17, t01;\
t01 = b   ^ c  ; \
t02 = a   | d  ; \
t03 = a   ^ b  ; \
z   = t02 ^ t01; \
t05 = c   | z  ; \
t06 = a   ^ d  ; \
t07 = b   | c  ; \
t08 = d   & t05; \
t09 = t03 & t07; \
y   = t09 ^ t08; \
t11 = t09 & y  ; \
t12 = c   ^ d  ; \
t13 = t07 ^ t11; \
t14 = b   & t06; \
t15 = t06 ^ t13; \
w   =     ~ t15; \
t17 = w   ^ t14; \
x   = t12 ^ t17; }

Here, w,x,y,z are the output and a,b,c,d are the input integers. If I well understood, the RND00 function is equivalent to $S_0$. If it's true, how did they get that code working ?

Define 16 functions like this make the code longer and not really understandable. Is there another way to code those functions with clearer instructions more like what's explained in the paper ?

Another question : What's the difference between bitslice mode and non bitslice mode in terms of performance and utility ? Why should one will prefer one instead of the other one ?

As you can see, I really don't want to copy the code. My objectives are to understand every step of the cipher and write my own readable code (optimized in C++11) in which it'll be easy to understand and follow.


texts:
According to wikipedia, a perfect hash function is a hash function that uses algorithms that has a certain random aspect to their logic. It is suppose to be collision-free.

However due to the pigeon hole principle where given a set of all possible preimages M & a set S where S is the set of all possible hash values resulting from H(M) = (S) & set M is bigger than set S. How does a perfect hash function have collision-resistant in this case?

Based on the answer given by poncho the pre-images are known beforehand & thus the hash function is structured in such a way that there exist a unique hash value for each message. However my confusion exist is that given a message space where each message is for example at least (4 bits long = 16 possibilities) & the hash value is return as (2 bits long = 4 possibilities) value. How can this still possibly be collision-resistant?

Summary, in a perfect hash function:

Must the bit length of the hash value be long enough to cover N number of messages?
Does it not simply make a perfect hash function as a specified lookup table for a set of predetermined message?

Another side question is in the wikipedia page there is a mention of a minimal perfect hash function. Is a hash function that distributes the hash value uniformly across S (Where S is the set containing all possible Hash value resulting from message space M)


texts: Path ORAM asymptotics for arbitrary block sizes

texts:
The Path-ORAM construction assumes that the data outsourced into the ORAM scheme is split into blocks of size $\Omega(\log^2{n})$. With respect to this assumption the authors state that their storage overhead is $20N$ and their bandwidth overhead is $\mathcal{O}(\log{N})$.

How would those those performance metrics be influenced if I do not make this assumption about the block size, e.g. I assume that the blocks are of constant size (and in particular independent of N). What would be the asymptotic/practical server-side storage overhead and what would be the bandwidth overhead in this case?


texts: Why does Salsa20 algorithm require incrementing word[8] and word[9] after producing cipher text message

texts:
I'm trying to get understanding of Salsa20 algorithm. There is an official specification from Daniel J. Bernstein at link. Everything in spec is clear and I could write an implementation on Swift.

But I met Salsa20 cipher algorithm implemented by other developers Crypto and TLS for C++11 , Salsa20 written on Python
The developers perform some operations with words at positions 8 and 9 after generating ciphertext message:

I didn't saw these operations in the original Salsa20 spec. What do these increments mean?


texts: Having CBC-MAC of a one block message, forge CBC-MAC of two blocks

texts:
This whole question pertains to CBC-MAC.

Let's say $a$ is one cipher block long, and the attacker knows the MAC $M(a)$ of $a$, which was generated with a random key. How can the attacker forge the MAC of a two block message under the same key?

For example, if I have $M(a)$, can I forge $M(b||c)$, where $b$ and $c$ are both one block each?

If that is not possible, is it possible to forge $M(a||b)$ or $M(b||a)$?