texts: Different implementations of SHA1, which one is correct?

texts:
I have noticed that different implementations of SHA1 give different results. As I'm currently programming my own SHA1 implementation (in MATLAB / GNU Octave), I wonder which one should I follow?

There are several implementations of SHA1 in Rosetta Code. Using the message Rosetta Code, most of them give SHA1 hash of 48c98f7e5a6e736d790ab740dfc3f51a61abe2b5.

There is also Tools for Noobs Online sha1() function, that gives the same hash as the examples in Rosetta Code.

In Rosetta Code, there are also two examples of computing SHA1 in Unix shell:

In my own computer (Debian Linux Wheezy amd64),echo 'Rosetta Code' | sha1sum gives a SHA1 hash of d350d93ccda0fbf2d5037dedd2f3763fe880b2c5 and echo 'Rosetta Code' | openssl sha1 also gives the same hash.

However, the Rosetta Code examples of computing SHA1 in Unix Shell use different message: ASCII string . According to Rosetta Code, echo -n 'ASCII string' | sha1 should give 9e9aeefe5563845ec5c42c5630842048c0fc261b, and echo -n 'ASCII string' | openssl sha1 | sed 's/.*= //' should give the same hash. When I try ASCII string as message in Tools for Noobs Online sha1() function, it gives the same hash as the examples of Rosetta Code on computing SHA1 in Unix shell. So I can conclude that all these implementations of SHA1 in Rosetta Code and also Tools for Noobs Online sha1() function give identical hashes.

In my own computer, using the message ASCII string I get the hash 4f9e000b925f5d96def1d9b3e21cdc11f1df6139 either by echo 'ASCII string' | sha1sum or echo 'ASCII string' | openssl sha1.

So, of all these implementations, only my own computer's sha1sum and openssl sha1 differ from the examples of Rosetta Code and Tools for Noobs Online sha1() function. Has this something to do with the UTF-8 vs. ASCII, processor type, endianness, message suffixing differences or is there something wrong in my Linux configuration?


texts: Why does NaCl's crypto_secretbox for xsalsa20-poly1305 require the first 32 bytes to be zero?

texts:
The NaCl web site says this is a requirement of the API, but its seems more than just an API issue. It means the first 32 bytes of the first salsa20 block are effectively ignored. I didn't see anything in the documentation that explains the reason for this.

Does ignoring the first 32 bytes of the first salsa20 block improve security in some way?


texts:
I am wondering how to solve the problem below:

Suppose we have a $MAC$ scheme $I=(S,V)$. There is another algorithm that can find a pair of texts $(m0,m1)$, with $m0≠m1$ such that $S(k,m0)=S(k,m1)$ for $1/10$ of the Keys $K$.What is the minimum $Adv$$MAC$$[A,I]$ for every adversary $A$?

MAC defined over $(K,M,T)$ is a pair of efficient algorithms $(S,V)$:

$S(k,m):$ returns a message athentication code $t$ which belongs to a set $T$
$V(k,m,t):$ returns a value $true$ or $false$ depending on the correctness of the received authentication code

$M$ is a set of all possible messages $m$
$K$ is a set of all possible keys $k$
$T$ is a set of all possible authentication codes $t$

Thanks in advance!


texts: Propagating CBC insecure Authenticated Encryption

texts:
why is Propagating CBC (PCBC) insecure for authenticated encryption?
I received the hint that I should feed a message of length $n$ and a message of length $n-1$ to it, but I don't really get what the result gives me, as we still have this Xor with the previous message.


texts:
Let $x$,$y$,$z$ be permutations. Then public key is $z=xyx^{−1}$ and $y$. Is permutation conjugate search problem easy? if yes, how to find $x$ from $z$ and $y$?
Let be a is Alice's secret key as large number,and X,Y,A=XaYX−a is public key.

encryption Bob pick at random number r,s and B=XrYX−r,C=XrAsX−r,and c=H(C)+m, and (B,c) is cipher text send to Alice.

decryption Alice calculate C=XaBX−a. Cause the discrete logarithm problem of permutation groups is weak,so Alice can calculate C from B. Finally Alice get plain text as m=H(C)+c.

I assume permutation dimension of X is 1988 and permutation is represented as array form.X's order have 256-bit integer.

Is this cryptosystem insecure ?


texts: inverse problem about scalar multiplication on elliptic curve

texts: Let $E$ be an elliptic curve over a finite field $F_p$. Given $n$ be a positive integer and $Q$ be a point on $E$, assume that $Q=nP$, how can we find this $P$? We can assume that $n|p-1$. If $n$ is "small", I would imagine that it is possible using division polynomials. Is it a difficult problem if $n$ is large enough? How difficult is it?


texts: Use of ElGamal encryption for signature generation

texts:
If RSA (textbook RSA that is) generates a digital signature by using the sender's private key, couldn't any cryptosystem (the only two that come to mind are RSA and ElGamal) capable of asymmetric encryption do the same?

For example, I've read that ElGamal is encryption only. Why can't ElGamal encryption (not DSA) do the same that RSA does?


texts: Proofs by reduction and times of adversaries

texts:
I have some difficulties to understand, when we construct a reduction, how we determine the time for the constructed adversary to break a target security property.

In general these details are not explained in books.

Do you have some examples in which the time $t$ for the adversary $A$ is not equal to $t'$, the time for the constructed adversary $A'$ to break something supposed secure?

Is the time very important?
Why are the resources given to the adversary not sufficient to describe a security reduction?


texts: Generating 1024 bits of entropy from a seed

texts:
I need to generate 1024 pseudo-random bits from a 100 bytes string seed (only valid lowercase chars)

One thing I'm pretty sure would be secure enough would be to repeat this 100 bytes string 20 times and encrypt it (using itself as the key with AES for instance) and then return the first 1024 bits

Does that seems fine?
Is there a more "standard" way to d that (some simple/secure key expansion algorithm)?


texts: How to impelement mapping point Curve25519 to weierstrass point?

texts: I am implementing a ECDH using Curve25519 to communicate two system. One system have library that use for weierstrass curve only, it can define with domain parameter like p, a, b, G_x, G_y. I have read and find that Curve25519 can converse to weierstrass, I can find that converse domain paramerter for Curve25519 here (https://tools.ietf.org/id/draft-ietf-lwig-curve-representations-02.html). After that, I need converse point from Curve25519 to weierstrass, I find the mapping is (u,v) -> (x, y) = (u + A/3, v) but I do not understand that. Example with base point of Curve25519, (u, v) = (0x9, 0x20ae19a1b8a086b4e01edd2c7748d14c923d4d7e6d7c61b229e9c5a27eced3d9), after converse in weierstrass, base point is (0x2aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaad245a, 0x20ae19a1b8a086b4e01edd2c7748d14c923d4d7e6d7c61b229e9c5a27eced3d9), with A = 486662, B = 1. That seem not correct with mapping, so is that operator devision is not normal division. What exactly I need to converse point in form Curve25519 to weierstrass curve, thank you.


texts: TPM specification physical presence requirements

texts:
I am looking at TPM Main-Part 1 Design Principles_v1.2_rev116_01032011 and on page 69 of pdf, equivalent to page 57 of the document itself,there is comment on physical presence as follows: "Observe, the reverse logic surrounding the use of TSC_PhysicalPresence command. When the physicalPresenceCMDEnable flag is set and the physicalPresenceLock flag is not set, the TSC_PhysicalPresence command may set physicalPresenceV." This is in relation the the following diagram:
I do not see any reference to physicalPresenceLock in the diagram. I want to validate that they are talking about physicalPresenceCMDEnableV flag. That is the only flag in the diagram relevant to TSC_PhysicalPresence() which is not set. Am I reading this right? Is this a typo?


texts: Encrypting a string of arbitrary size with a big integer

texts:
I am currently writing Python script that initiates a secure handshake. I am kind of reinventing the wheel here, so that I can properly learn it.

Now, I have Diffie-Hellman mostly working from scratch, and both client and server has agreed on a key to use. This key is an integer of ~2048 bits (2047 most of the time. 2046 is the lowest I've seen). The question then is, which cipher do I chose for encryption data of arbitrary length with this key?

Also, when the client and the server later has exchanged public keys, is there any reason why I should/should rely on said public key encryption alone, and not use the above mentioned integer as well?


texts: Is the context of "constant time" algorithms inclusive when you have a clock control?

texts:
There is generally a push to make algorithms and components constant time to be resistance to side channel attacks.  For instance, AES-NI instructions take as many cycles as rounds; however, I can lower the CPU voltage and increase the clock speed until I see errors on the result.  The circuits are only constant time if they satisfy the critical path propagation between latch boundaries.

When I read a paper that specifically says that it robust to side channel attacks because the algorithm is constant time, is the assumption that one does not have clock/voltage control?

To elaborate a bit on the boundaries that I mention, consider the following image that represents a pipeline of logic:

In the image, there is a logic cloud that is operating on n-bits of information with a result.  This is much like what a multiplicative inversion module looks like in hardware where you load the starting value and you then "latch" the result.  The fundamental idea is that the clock line, CLK, is slow enough that you satisfy the worst-case propagation condition electrically.  If I decrease the process voltage, and keep the clock the same speed, I can violate the path requirements.  If I increase the clock speed for the same voltage, I also violate the requirements electrically.


texts: Is it possible that two distinct RSA moduli share both of their prime factors?

texts:
I am using an algorithm (can be found here1) that can compute efficiently the GCD of multiple RSA keys. It intended for RSA keys that were generated with low entropy and may have one of their primes in common.

In the documentation it is stated that:

  if a modulus shares both of its prime factors with two other distinct moduli, then the GCD will be the modulus itself rather than one of itsprime factors


texts:
I am using ECIES (Cryptobox as poncho pointed out) for public key encryption with ECC between Alice and Bob with secret/public keys $(a,A)$ and $(b,B)$ respectively. So Alice encrypts to Bob with

$$
Encrypt(aB,Message)
$$

Additionally I would like to encrypt some of Alice's data such that only she can decrypt it. Is it safe to use ECIES to compute a shared secret from Alice's secret and public key as in

$$
Encrypt(aA,Message)
$$

I know I could randomly generate a public key, but then I would have to store this key somewhere which I would like to avoid.


texts:
I noticed that several hash algorithms, in this case MD5, defines some constants.

MD5 defines 64 constant values (the shift count per round) which also gets expand (via sine) to a summand for a specific round. It is like a lookup table.

But I cannot see anything (no documentation, no implementation,...) that calls this table an substitution box (S-Box). But I saw some implementations that use a variable called "S" for this table. A hint?

So my question is: Is it valid to call this table an S-Box? Or is it only common to call this kind of table an S-Box when it's used into a real encryption/decryption?


texts: Is there a maximum amount of data which can be encrypted using a symmetric (AES256) key?

texts:
I am working on an application where we will be encrypting billions of small (< 2,000 bytes) records.  Combined, we are facing many TB of data.  Each record will be encrypted independently, using a unique IV/nonce.

We are aware of the restrictions around the reuse of IV/nonce values and the limits on the amount of data which can be encrypted using a key/IV pair (the NIST SP 800-38 series).  Given that each record will use a unique IV, this will likely be the primary factor driving the rotation of keys.

Is there a maximum amount of data - regardless of the number of encryption operations using a unique IV/nonce - where the AES key itself should be rotated, or is the retirement driven entirely by the restrictions set by block chaining mode?


texts: memory-hard KDF that's just a giant permutation?

texts:
Why aren't there memory-hard KDF functions that simply build a 1GB permutation and permute it? Then hash the 1GB result. For example, use a hash function (unfixed output mode) on the key+salt and use the output to populate the starting state of the permutation.

If you go crazy with the permutation by sacrificing side channel resistance you can make it extremely GPU or even ASIC unfriendly (use a lot of operations that would make such an ASIC resemble a CPU and not be much better).

Since some clarification was requested, let the permutation have a Feistel cipher component (in addition to something else that would provide it known cryptographic strength) that would use a lot of data-dependent branching which would require speculative execution for performance and utilize/stress other circuits found in a CPU - for example slice the 1GB chunk into 128 bits and do an AES round as an additional non-linearity in the permutation.

Then perhaps each round perform a hash of the permutation state and have the hash bits determine parameters in the algorithm of how to do the next permutation.

I think the idea is clear, just make sure that throughout the process there would be a structure present that would follow common cipher design principles of diffusion and confusion - which for a 1GB block of data would require a lot of rounds, but that's alright since we are dealing with a KDF that aspires to be memory-hard and also compute intensive.


texts: GCM decryption and clear text processing

texts: When using GCM mode decryption, is it necessary to wait for the decryption to complete, (and thus being able to see if the integrity of cipher text is OK) before beginning processing the clear text output, or is it possible to begin processing the clear text in parallel without any risk, regarding chosen cipher text and timing attacks? (Of course, I understand that the clear text would have to be discarded anyway, if the integrity of ciphertext appeared to be bad)


texts: Does fixing partial bits of a SHA256 hash increase the probability of finding a preimage using the meet-in-the-middle attack?

texts:
Let’s say I want to find a partial rather than full preimage using the meet-in-the-middle attack. For example, my goal is to find a preimage so that the first 76-bit output of the hash are all consisted of the number 1.

Does finding a partial preimage have a better chance of success than finding a full preimage using the meet-in-the-middle attack? If so, what is the complexity of this attack?

EDIT: I know that there is no full-round meet-in-the-middle attack against SHA256 to find full preimages. However, my question is: would it be easier to execute a full-round meet-in-the-middle attack to find a partial preimage instead?


texts: In HMQV, can one use multiple identities with one public key?

texts:
The HMQV protocol has 2 "identity" fields $\hat{A}, \hat{B}$ that are used in the dual signature - and it tries to guarantee that any properly-generated session key is only shared by a single $(A, B, \hat{A}, \hat{B})$ 4-tuple.

However, the paper isn't particularly clear whether a party can use multiple, potentially attacker-controlled, identities.


texts: How is a "SHA256 reduced by X of Y rounds" built?

texts:
Wikipedia reports:

  A 2011 attack breaks preimage resistance for [...] 52 out of 64 rounds for SHA-256. Pseudo-collision attack against up to 46 rounds of SHA-256.

I am having trouble determining/understanding whether the "Message Expansion" of SHA-256 is the one reduced (splitting the 512-bit message block into 16 words, and expanding them into 64 expanded message words), or the "State Update Transformation" is the one reduced (starting from the previous 256-bit chaining value, which is updated by applying the step functions 64 times).

I have the feeling that both are reduced, but I am not sure...


texts: Construction of Isomorphism between Galois Fields

texts:
I am trying to create an isomorphism between GF($2^8$) and an extension field in GF($(2^4)^2$).
The finite field GF($2^8$) uses the Rijndael(AES) irreducible polynomial.In this field I have found 128 generators(G1).

I have found 3 irreducible polynomials(IR1) in GF($2^4$). For each irreducible polynomial, I have found 120 irreducible polynomials(IR2) in the extension field GF($(2^4)^2$). For each of the 360 pairs of (IR1,IR2) I have found the 128 generators(G2).

So, now I am trying to create an isomorphism using (G1,G2) by mapping $G1^i \to G2^i$ ( by doing multiplications in their respective fields). What I find is that many pairs of (G1,G2) are not forming isomorphisms . This was verified by checking if map(1) +map(2) =map(3).

Is this supposed to happen? Why/Why not? Please explain in detail.

Note:My knowledge in isomorphisms is not great and was unable to find good online sources for the same.


texts:
I was reading this set of lecture notes on commitment schemes, where they define a commitment scheme $\text{Com}(b, r) = f(r), h(r) \oplus b$ as a secure commitment scheme. In this case, $f : \{0,1\}^n \rightarrow \{0,1\}^n$ is a one-way permutation, $h : \{0,1\}^n \rightarrow \{0,1\}$ is a hard-core bit of $f(\cdot)$, and $r$ appears to be a random string from $\{0,1\}^n$ (the notation is $r \leftarrow_R \{0,1\}^n$, but I'm not really sure what this actually means and it would be super helpful if someone could clarify what the notation means here!).
My question is what the $f(r), h(r) \oplus b$ means. What is the comma doing? Does this mean that the commitment scheme returns two outputs (I was under the impression that commitment schemes only return one output)? Or am I supposed to combine $f(r)$ with $h(r) \oplus b$ somehow? Thank you for your help!


texts: Random permutation of bit strings of length $n$, where $n$ can be any positive integer?

texts:
I need an efficient, invertible random permutation of $n$-bit strings, defined by a $128$-bit key. $n$ can be any positive integer from $6$ to $128$. I have no requirements on the security of the permutation; only that it is random (i.e. that outputs for different keys are uncorrelated).

Many standard algorithms exist for $n$ of $32$, $64$, and $128$ bits. I wondered if the Sponge Construction of Keccak could be used to transform such permutations into $n$-bit permutations. I understand the sponge construction generates a function of variable input length and arbitrary output length. However, it is not clear that if I use it to generate a function to turn one $n$-bit string into another $n$-bit string, that that function will encode a random permutation. Does it?


texts: Why is private key chosen to be less than chosen prime in diffie-hellman?

texts: since the public key is calculated as Y=(alpha^private-key)mod(chosen prime) and alpha is a primitive root of prime, when Y becomes public then private key can be calculated easily right? since there is a unique private key less than chosen prime that will satisfy the equation. I think I'm missing something here. Please help.


texts: Modifying a [CRC32] checksum protected file

texts:
I dont want to ask for help without showing how far I came by myself, so this is what I have so far:

The file of interest is an encrypted/obfuscated .bin script, which cotains information on certain weaponstats eg. damage or accuracy. It is part of an older computergame. The raw file containts only hexvalues, which I "converted" to their Characters using extended ASCII. The output wasnt satisfying at all, untill I found out, that it was obfuscated using single byte XOR. Since there are only 256 different possible ways I went manually through all of them and had success with Key 42. This is what the decrypted script looks like:

I made my own small Tool, which decrypts the file hex -> ascii -> xor decrypt and saves the changes with hex <- ascii <- xor encrypt. So right now I am able to manipulate some weaponstats and save the file into its previous format.

When I try to start the game with my manipulated file it appears a CRC checksum error and it wont start. I was aware about this and did some research already, the checksum used is definitely CRC32 and I found out, that you can force a files checksum to any value by appending 4 bytes, but it obviously wont work due to the file format:

The CRC32 checksum is now similar to the untouched file, but the game cant read it and doesnt start and this is where Im stuck.

So what to do now? In theory I should be able to make some changes with getting the same checksum using gaussian elimination, but I really need some help to point me into the right direction.
It would be enough to change 1 hex-value as a first try and see what to change next to get the same CRC checksum. From there I could think about changing stuff, which makes sense in terms of manipulating weapons. So what if I change the very first hex-value in the file "16" to "17", what do I have to change next to get the old checksum back? Is that the right attemp? I am quiet new to all this, but I dont want to give up yet.

This folder contains the original file (items.bin) .txt to show in browser, an at 2 values maniuplated one and the plain text script. Original checksum is '3DD1ECB7'

Thanks in advance.


texts: What's a good P to use in ElGamal key generation?

texts:
I need to generate a 1024 bit ElGamal key on Android, and key generation takes forever (~10 minutes on a Galaxy Nexus), I suspect because it take so long to generate a safe prime.

Is it dangerous for me to use the same safe prime p for all devices using my app?

Where can I find a list of 1024 bit and 2048 bit safe prime numbers?

I'm using it for encryption, and I'm wary about hard-coding a P/G because of the this attack. I know it says only for signatures, but I'm still wary of introducing weakness because I am by no means an experienced cryptographer. The IETF has a list of good Ps to use, but they advocate using G=2, as seen here.


texts: Security in case of Malicious and Augmented Semi-Honest Adversaries

texts:
On page 29 of Book Efficient Secure Two-Party Protocols by Y. Lindell and C. Hazay, there's this proposition:

  Let π be a protocol that securely computes a functionality f in the presence of malicious adversaries. Then π securely computes f in the presence of augmented semi-honest adversaries.

There's a proof following this proposition. In the proof, they say that the distribution over messages will be identical since the real adversary will follow the protocol exactly. But since an augmented semi honest adversary might change the input, won't the distribution over messages change as well?
Also, why can't a similar proof be drawn for security in case of semi-honest adversaries?

Moreover, is the definition of security in case of augmented semi-honest adversaries analogous to that in case of malicious adversaries? In the book, I was unable to find a formal definition of security for augmented semi honest adversaries.

P.S: This is the proof:

  Let π be a protocol that securely computes f in the presence of malicious adversaries. Let A be an augmented semi-honest real adversary and let S be the simulator for A that is guaranteed to exist by the security of π (for every malicious A there exists such an S, and in particular for an augmented semi-honest A). We construct a simulator S′ for the augmented semi-honest setting, by simply having S′ run S. However, in order for this to work, we have to show that S′ can do everything that S can do. In the ma- licious ideal model, S can choose whatever input it wishes for the corrupted party; since S′ is augmented semi-honest, it too can modify the input. In addition, S can cause the honest party to output abort. However, S′ cannot do this. Nevertheless, this is not a problem because when S is the simulator for an augmented semi-honest A it can cause the honest party to output abort with at most negligible probability. In order to see this, note that when two honest parties run the protocol, neither outputs abort with non-negligible probability. Thus, when an honest party runs together with an augmented semi-honest adversary, it too outputs abort with at most negligible probabil- ity. This is due to the fact that the distribution over the messages it receives in both cases is identical (because a semi-honest real adversary follows the protocol instructions just like an honest party). This implies that the simu- lator for the malicious case, when applied to an augmented semi-honest real adversary, causes an abort with at most negligible probability. Thus, the aug- mented semi-honest simulator can run the simulator for the malicious case, as required.


texts: Reason for 3 rounds ChaCha in ChaCha20Poly1305@openssh

texts:
OpenSSH uses a slightly different ChaCha20Poly1305 AEAD construct then the one proposed by A. Langley and others for TLS.

The TLS version

The openSSH version (and here)

The openSSH version uses two 256bit keys.
First key is used for deriving the Poly1305 MAC key and for encrypting the actual payload
The second key is used to encrypt the AAD (the 4 byte packet length in the openSSH case)
This construct result in at least 3 rounds of ChaCha20 for small messages (<=64 bytes).
The first ChaCha20 round for deriving the 256bit Poly1305 key spits out 64bytes where the last 32bytes are unused.
The second ChaCha20 round encrypts the AAD data (a 4 byte packet length)
The third (and more) ChaCha20 round(s) encrypts the actual packet payload.

For small messages, this seems to generate an unnecessary overhead of up to 33% computation time (in case message payload is less then 64 bytes).

The question

Why not use the unused 32bytes from the Poly1305 key derivation ChaCha20 round in order to encrypt the packet length (or say the AAD data up to 32 bytes)?
Is it cryptographically required to use a 2nd ChaCha20 context with a 2nd key to encrypt the packet length (the AAD data),... or in other words, is it more secure to use a 2nd key (that very likely comes from the same single shared secret as the first key) rather then use a single key and encrypt the AAD data from the same ChaCha20 round that derived the Poly1305 key?


texts: What is the progress on the MIT LCS35 Time Capsule Crypto-Puzzle?

texts:
Ron Rivest posed a puzzle in 1999.  MIT LCS35 Time Capsule Crypto-Puzzle.

  The problem is to compute $2^{2^t} \pmod n$ for specified
  values of $t$ and $n$.  Here $n$ is the product of two large primes,
  and $t$ is chosen to set the desired level of difficulty of the puzzle.

  Note that the puzzle can be solved by performing $t$ successive
  squarings modulo $n$, beginning with the value $2$.  That is, set

  $W(0) = 2$,
  $W(i+1) = W(i)^2 \pmod n \quad$    for $i\ge0$,

  and compute $W(t)$.
  There is no known way to perform this computation more quickly
  without knowing the factorization of $n$.

In 1999 they predicted that we'd have 10 GHz processors by now.  I realise that raw GHz is a dumb way to measure speed, but how fast are computers for this kind of "intrinsically sequential" computing?

I guess my questions are:

1) What is the state of the art for computation which can not be parallelised?

2) Has anyone claimed to make any progress with this challenge?


texts: Most efficient way to perform secure bitwise multiplication

texts:
Suppose there are two parties with binary strings of equal length. What would be the most efficient way to securely calculate the bitwise multiplication of these strings (i.e if one party has 0101 and the other party has 0011 then the product would be 0001)?

My current thinking is that some sort of single-bit multiplicatively homomorphic cryptosystem would work best, but I have been unable to think of any (ElGamal, for example, does not support encryption of 0).


texts: Creating UID's using hash functions - most appropriate hashing algorithm?

texts:
I have circa 1 million datapoints, each with a unique integer ranging from 6 to 24 digits:

exampleDataPointOne: 655092
exampleDataPointTwo: 333402221
exampleDataPointThree: 332021
...
exampleDataPointN: 903232211

I want to run each of these unique integers through a hash function, with the objective of 1) maintaining the uniqueness, 2) obscuring the underlying integer value and 3) having a hash output with a length of <= 34.

I've looked around for potential hash algo's that are a good fit, such as BLAKE, md5 and the sha family of hashes.

Given my requirements, what is the most advisable hash algorithm to use?


texts: What is the theoretical and practical status of mental poker?

texts:
I'm able to find a lot of scattered papers on the development of mental poker since RSA proposed the initial solution but no recent report (i.e. after 2005) on what is the status of the problem, eg:

What are the remaining open problems/challenges?
Can we call it solved? For example, has the "dropout" problem been solved (e.g. [1] suggests so, but has it been verified?)?
Have the performance problems been solved ?
Is there an implementation of the algorithms / protocols ?
What is the latest performance improvements (e.g. is [2] up to date to the fastest protocols known)?

[1] http://crises-deim.urv.cat/webCrises/publications/isijcr/lncs3592dropout.pdf
[2] http://www.nongnu.org/libtmcg/libTMCG.pdf


texts: Is it right about an example of bilinear map $e$?

texts: The equation for the elliptic curve is $y^{2} = x^{3} + x$ and is defined over the field $F_{q}$ for some prime $q\equiv 3 \pmod 4$, and set $q=307$. Choose random generator $g=[182, 240]$. My question is that how do I construct a bilinear map $e$ and compute $g_{1} = e(g, g)$?


texts: Is it practical to use a stream cipher in a block cipher mode?

texts: My idea is to use a stream cipher encrypting 16 bytes at a time as a primative block cipher in a mode of operation such as CBC mode.  Is this practical or useful in any way?


texts: Can the RSA accumulator scheme be converted to Elliptic Curve math?

texts:
Is it possible to translate the RSA accumulator scheme directly to EC without requiring bilinear pairings?

In RSA we have:

$A_{n+1} = A_n^c$ st.             $\{c \: \textrm{prime} \: | \: c \in [\mathcal{A}, \mathcal{B}]\}$

$W = A_n$

$A_{n+1} \stackrel{?}{=} W^c $

Would this work in EC like this?

$A_{n+1} = c A_n$

$W = A_n$

$A_{n+1} \stackrel{?}{=} c W $

Where $A_0$ is a generator point on the curve and $c$ is prime.

If not, then why?


texts: Brute force, get AES keys by multiple plain-texts with their cipher-texts

texts:
I know that the encryption is AES, and I have multiple plain-texts with their cipher-texts, I don't know the encryption mode (ECB, CFB, etc ...) actually, but I know that the keys and the IV Key (if it's used) are static not changeable.

  How can I get the keys, or is there are a way to encrypt a text with the same key, so I can get the cipher-text of any plain-text I want ? Is there any tool or service can I pay to do that ?


texts: Importance of Backward and forward secrecy

texts: Which security feature is more important in security protocols being used in different applications? Forward Secrecy or Backward Secrecy


texts: obscuring timing attacks in vulnerable libraries

texts:
Let's say you're using a library that you know is vulnerable to timing attacks. Short of switching libraries all together it seems to me that putting a sleep in the code for a random number of microseconds (or seconds or whatever) would be sufficient to obscure the time it took?

Like why do RSA blinding when you can just sleep for a random number of seconds before or after the RSA decrypting code is ran?


texts: Malicious OT from 'Efficient Secure Two Party Protocols' --- defining the simulators

texts:
I am looking at Protocol 7.5.1 in Hazay and Lindell's Efficient Secure Two Party Protocols, it can found here
(p 201).

A similar protocol is proven secure in Section 7.4 (p190) and the proof is given in a good level of detail. For Protocol 7.5.1 however the proof given is only short. References are given to where the protocol is taken from, but again there I am struggling see a detailed proof.

In particular I am struggling to write down the exact Simulators that are needed to prove security in the malicious setting for each party. I would like to be able to see a proof that is similar in detail to Protocol 7.4.1 in the previous section. For one party we need to reduce the the DDH problem, and the other we can show the real and ideal views are equal...I think?

Thanks in advance.


texts: Why is Poly1305 popular given its 'sudden death' properties?

texts:
ECDSA has the undesirable property that if a key pair reuses a nonce in a signing operation, the cryptosystem experiences catastrophic failure in the form of private key leakage. I've heard this referred to as "sudden death" cryptography. Of course the PS3 misuse of ECDSA is probably the most widely publicised incident.

One advantage of DJB-advocated cryptosystems like Ed25519 is that they lack this weakness. The Ed25519 website states that "hash function collisions do not break this system."

A perfect implementation of ECDSA will be problem free, but since implementation flaws are inevitable, it seems preferable to use cryptography without huge exposed sharp edges.

This being the case, I am puzzled by the DJB's and other's advocacy for an authentication function that exhibits "sudden death" in the event of inadvertent nonce reuse.

Is the use of Poly1305 really informed only by performance? If so, why is this so crucial? The widespread use of e.g. HMAC suggests that MAC computation costs are tenable as they are and without pressing issue. I don't understand why Poly1305 is receiving such preference when it seems so dangerous. Can someone explain this?


texts: Canonical embedding vs. plaintext slots in Ring-LWE

texts:
I'm working on the canonical embedding mentioned in
[LPR10] and [LPR13]. What confuses me is that the difference and the relationship between the canonical embedding and the concept of ''plaintext slot'' in other works (e.g., [SV11]).

Let's focus on the $m$-th cyclotomic number field $K = \mathbb{Q}(\zeta_m)$ where $\zeta_m$ is an abstract element of order $m = 2^k$ for some $k$. For canonical embedding $\sigma$, it is comprised of $\left| \mathbb{Z}_m^* \right| = \varphi(m)$ embeddings $\sigma_i: K \mapsto \mathbb{C}$. More precisely, $\sigma_i(\zeta_m) = \omega_m^i$ and $\sigma(a) = (\sigma_i(a))_{i \in \mathbb{Z}_m^*}$ for the primitive $m$-th root of unity $\omega_m$ and $a \in K$. The canonical embedding maps an element in $K$ to the vector space $H$ which is defined to be
\begin{gather}
H = \{ \textbf{x} \in \mathbb{C}^{\mathbb{Z}_m^*}: x_i = \overline{x_{m-i}},\ \forall i \in \mathbb{Z}_m^* \}.
\end{gather}
Notice that $x_i = \overline{x_{m-i}}$ holds for all $i \in \mathbb{Z}_m^*$. So using canonical embedding, it seems that there are only $\varphi(m)/2$ instead of $\varphi(m)$ ''slots'' for an vector in $H$ to encode complex numbers. If we want to encode a vector $\mathbf{v}$ of real numbers into an element in $K$ via $\sigma^{-1}$, is it true that the number of elements in $\mathbf{v}$ should be at most $\varphi(m)/2$ instead of $\varphi(m)$? (Question 1)

To generate plaintext slots, we can apply Chinese Remainder Theorem (CRT) to the polynomial ring $R_p = \mathbb{Z}_p[X]/\Phi_m(X)$ for the $m$-th cyclotomic polynomial $\Phi_m(X)$. Note that $\Phi_m(X) = \prod_{i \in \mathbb{Z}_m^*} (X - \zeta_m^i) \mod p$ where $(\zeta_m)^m \equiv 1 \mod p$ and CRT will result in $\varphi(m)$ slots for component-wise addition and multiplication. This CRT is indeed a kind of number-theoretic transform (NTT) by evaluating some polynomial $b \in R_p$ at $b(\zeta_m^i)$ for $i \in \mathbb{Z}_m^*$, which is quite similar to the situation where the embedding $\sigma_i$ is applied to $\mathcal{O}_K$, the ring of integers of $K$. Why do we have $\varphi(m)$ slots here while there are only $\varphi(m)/2$ ''slots'' in canonical embedding? (Question 2)

Many thanks

My understanding (updated on 29/07/19)

It seems that the difference between canonical embedding and plaintext slot comes from the difference between $\omega_m$ and $\zeta_m$, in which $\omega_m^m = 1 \in \mathbb{C}$ and $\zeta_m^m = 1 \in \mathbb{Z}_p$. For some $a \in \mathcal{O}_K$ and $i \in \mathbb{Z}_m^*$, we have
\begin{gather}
\sigma_i(a) = a(\omega_m^i) = a(\overline{\omega_m^{m-i}}) = \overline{a(\omega_m^{m-i})} \in \mathbb{C},
\end{gather}
in which the last equality is derived from the property of complex conjugate. The last equality implies that once one half of the $\sigma_i(a)$'s are fixed, the rest of them will be fixed as complex conjugate, which results in the factor $1/2$. However, note that there is no counterpart of this property of complex conjugate in $\mathbb{Z}_p$. That is, for some $b \in R_p$,
\begin{gather}
b(\zeta_m^i) = b((\zeta_m^{m-i})^{-1}) \neq (b(\zeta_m^{m-i}))^{-1} \mod p.
\end{gather}
So it is safe to encode different values to the $\varphi(m)$ slots and there must exist a coresponding polynomial in $R_p$ using NTT.

Am I right?


texts: Asymmetric CSPRNG where the public key only works backward

texts:
Is there an asymmetric cryptographically secure pseudo random number generator in which the public key only goes backward? For example, I'd like to generate 5,000 digits, then provide the public key and RNG state to another party. Then they'd generate the same digits backward from 5,000 to 1. The second party should not be able to calculate the digits from 5,001 onward.

Edit: Here's a working demo of DannyNiu's RSA approach.


texts: Are DSA and ECDSA provably secure assuming DL security?

texts: Is there proof that the DSA construction, also used by ECDSA, is secure assuming that discrete logarithms in the relevant group representation are difficult?


texts: Does the position of the salt improve its effectiveness when hashing?

texts: Seems most documentation I have read suggests the salt should prefix the value to be hashed. Is this just for consistency, or is the salt more effective when prefixed?


texts: Full diffusion or Partial diffusion between s-box applications?

texts:
In regards to maximizing active s-boxes: is it advantageous to apply the non-linear layer after complete diffusion of the state, rather after then partial diffusion?

Using AES as an example, with the well known mixColumns and shiftRows combination: What if this linear diffusion layer were applied twice in succession between s-box applications, instead of just once?

Doing the math for the regular AES with 2 rounds is simple:
\begin{align}
    1 + 4 &= 5\\
    4 + 16 &= 20 \\
    5 + 20 &= 25\\
\end{align}

The first number in each row is the number of different s-boxes at the input of the round.
The second is the number of differences at the output of the round.
The third is the sum of the two.
The first row represents round 1
The second row represents round 2
Finally, the two rounds are summed to give the total minimum number of active s-boxes.

So to simulate a double application of the linear diffusion layer, I tried substituting 16 for 4, but was unsure of how to proceed:
\begin{align}
    1 + 16 &= 17\\
    16 + 256 &= 272\\
    17 + 272 &= 289\\
\end{align}

or should it be:

\begin{align}
    1 + 16 &= 17\\
    16 + 32 &= 48\\
    17 + 48 &= 65\\
\end{align}

Or something else entirely? How many active s-boxes over the course of two rounds would such a variant of AES have?

Put succinctly, I guess I really want to know: Is there an cryptanalytic advantage to diffusing the entire state before applying the s-box layer? Or is it better to apply s-boxes more frequently, with "just enough" diffusion between them?


texts: Comparing the first 50 bits of a hash Vs. the last 50 bits of hash

texts:
If I had a hash function outputting a 256 bit hash, would there be any discernible difference comparing the last 50 bits of 2 hashes versus comparing the first 50 bits?

I guess what I am trying to say is can you have 2 hashes that finish with the same 50 bits yet have the first 206 bits different? (Assuming we are using Merkle-Damgård setup)

My gut says it shouldn't be any different because theoretically a hash should use all possibilities of hash values with equal randomness.


texts:
Is my protocol correct?

For fun, I tried to design a protocol that would allow off-the-record communication. I'm not sure it works, I have a feeling there might be a problem with it that I'm not seeing. Please tell me whether you see a problem with it.

Here's a dramatization of the protocol I'm imagining:

  Alice wants to send a message to Bob such that Bob would know it was sent by Alice, but couldn't prove it to Dan.

  Alice creates a disposable persona Charlie (an RSA keypair) and talks to Bob using Charlie.

  Charlie: "Hello Bob! I wish to send you a message that you'll know is from Alice, but couldn't prove to anyone else!"

  Bob: "Okay, here's a string X, it's the public key out of an RSA keypair I just randomly created, which I know for a fact you didn't tamper with."

  Charlie: "Cool, I got X, but I'm not including it in this message. Here's Z, a random string I just came up with, which I know for a fact that you didn't tamper with."

  Bob: "Cool, here's Y, which you can verify is the private key of X. Now let's take (Y xor Z) to be our W, which is a number we both know is random, but that none of us can prove to outside parties that it's not random. We're not sending W over the line because we both know what it is."

  Charlie: "Here's the message M I want to prove to you is sent by Alice. I'm sending you (SHA1(M) xor W) signed by Alice's private RSA key."

From Bob's prespective, everything's legit. He knows that no one could know what the number W was before he revealed the private key Y. Thanks to RSA, he knows that Alice made the message (SHA1(M) xor W), meaning that Alice intended to send the message M.

But if Bob were to show these messages to Dan, he couldn't be sure that Alice indeed sent M; perhaps Bob is trying to cheat him? Perhaps Bob composed message M himself, with no connection to Alice, and built the Charlie persona himself just to make it look like Alice sent the message? Let's see how Bob could have done that.

Maybe Bob obtained, in some way, an arbitrary string F signed by Alice's keypair from a past communication with her. He calculated (SHA1(M) xor F) and called it W, so now he can say he has Alice's digital signature on (SHA1(M) xor W), which is just (SHA1(M) xor (SHA1(M) xor F)) which is just F. He created the random keypair X and Y, and calculated Z, which is (Y xor W), which makes W be (Z xor Y). Then he created the disposable Charlie persona and constructed the entire fictional thread of conversation between them which includes all these numbers.

Bob knows he didn't do all of that, but Dan can't be sure, and thus our objective is reached.

Are there any problems in this protocol that I didn't think of?


texts: When is data origin authentication necessary but non-repudiation not?

texts:
I have been considering this question now for a week and I just cannot find an answer.

I understand that non-repudiation cannot be provided without data origin authentication but I cannot think of an application which satisfies that non repudiation is not necessary.

Can anyone suggest an example of an application where we need to know who sent the data but it doesn't really matter if they later deny that they sent it?


texts: What's the proper choice for the block size of a sponge-based hash?

texts:
While having a discussion about the future of Keccak in our library, we came to the discussion of how to properly assign a "block size" to Keccak (or more generally any sponge-based hash if possible), especially for use with HMAC (mostly out of API compatibility reasons).
The block size itself is a phenomen from the days when Merkle-Damgard hashes were the hash-functions of choice (such as MD5, SHA-1, SHA-2) and the HMAC security proof relies on the fact that the key is padded to at least a full block size and thus the block size requirement can't be eliminated from the HMAC interface.

So what's the cryptographic standard / recommended practice to assign a block size to Keccak (or a sponge-based hash)?


texts: a homomorphic operation on Paillier encryption

texts:
Assume  $N=pq$, where $p$ and $q$ are two strong prime numbers.

Also, assume we have  finite field $\mathbb{F}_u$ where $u$ is a $112$ bit prime number. Let $r_i$ be a uniformly random element of $\mathbb{F}_u$.

Let $(r_i)^{-1}$ be multiplicative inverse of $r_i$ in ring $Z_N$.

We encrypt a message as $c=E(r\cdot m)$ using Paillier encryption.

Question 1: Given $c$ and $(r_i)^{-1}$, can we "always" perform $c^{(r_i)^{-1}}=E((r_i)^{-1}\cdot (r_i)\cdot m)$ such that its  decryption value only contain $m$?

Question 2: given $E(m)$,  how can we chose its additive inverse $m'$ such that $E(m).E(m')=E(m+m')$ so its decryption value would be 0? should $m'\in \mathtt{Z}_N$ or $m'\in \mathtt{Z}_N{^2}$


texts:
I would like to compare the security of these two QKD protocols which both use entangled photons that are distributed between the users Alice and Bob. In the case of E91, the photon is measured randomly in 3 different bases which allows to violate a Bell inequality.

In BBM92, only measurements in two mutually unbiased bases are performed. This allows not to violate a CHSH inequality (S=2).

Does the violation of the Bell inequality lead to a higher security and therefore smaller assumptions needed to trust the source?

Can you give me a toy-model example that the source can use to deceive in the case of BBM92 but does not work in the case of E91?


texts: Making my steganography code more hard to detect and crack

texts:
I'm doing a college project about digital image steganography on MATLAB. So far i've been able to get the help i needed from cool guys on stackoverflow but i now need to make my algorithm more hard to detect. This is what i have so far:

My main function reads 4 grayscale RGB 24-bit images and one RGB 24-bit image to encode the four images into. The first two are supposed to be blueprints and the other two are images containing only text (in large size). All the images are of the same size.
Before encoding, the pixel positions of each grayscale image are randomly shuffled by (eg: the 1st pixel becomes the 24th pixel, the second pixel becomes the 300th pixel) this is done by generating a random permutation of numbers that represent the new pixel positions using a seed. This is done to make the code harder to crack to an outsider and the seed will act as a password that would be needed at the receiving end to recover the images.
The first shuffled grayscale image is encoded into the R plane of the RGB image, and the second shuffled image is encoded into the G plane. This is done by testing each pixel in each image eg: pixel in position (x,y): if black-->make lsb of the pixel in position (x,y) in the chosen plane =0. if white-->make lsb of the pixel=1.
The other two shuffled grayscale images that contain text only are combined to form one grayscale image by choosing a chessboard-like patter of pixel positions of the first and the complement pattern of the second. And the resulting grayscale image is encoded into the B plane of the RGB image same as done to the first two. And this is done in that way because you don't need much details to be able to read a text but you do need details to be able to make out a blueprint, the recovered text grayscales will be a little distorted but they'll be readable. Now the process encoding is done and S/N ratio is calculated for the resulting encoded RGB image to measure the difference from the original RGB image and in result the difference is not noticeable to the untrained eye.
Recovering the grayscale images is done by reversing the operations done to the encoded RGB image in reverse order.

So there you go. I'm now looking for a way to make my code way more harder to detect and crack. Maybe using Wavelet Transform? I've been reading on that for a while but i don't now how that would work for my project.


texts:
Can you please help with the following?

Let $C_1= g^r h_1^x h_2^y$, $C_2 = a^z$ and $C_3=(g^{r'}h_1^x h_2^y)^z$.

Basically, $C_1$ is a commitment on the values $x, y$ and $C_3$ is another, blinded commitment on the same values. $C_2$ is a commitment to the blinding factor $z$ of $C_3$.

We would like to prove in ZK that the values $x, y$ in the two commitments $C_1$ and $C_3$ are the same. Public knowledge are the values $a, C_1, C_2, C_3$ and the generators $g, h_1, h_2$. The secret values are shown in parentheses below:

\begin{align}
\pi = PK\{(r,  r', x, y, z):\; & C_1= g^r h_1^x h_2^y \; \; \wedge \nonumber \\ & C_2 = a^z \; \;\wedge \nonumber \\
& C_3=(g^{r'}h_1^x h_2^y)^z  \;    \} \nonumber
\end{align}

I have a proof but I find it somewhat ugly. It would be greatly appreciated if you can provide a more elegant one...

Thanks!


texts: Why doesn't the ability to sample a single random bit imply the construction of a random oracle?

texts:
I'm trying to understand exactly how the random oracle model differs from the standard model. In many proofs & applications there are some assumptions that some randomness is sampled (i.e. a bit $b \leftarrow\{0,1\}$).

My question is: given the ability to sample a single bit at random, can't we use that to construct a random oracle? Suppose we want to simulate a random function $H:\{0,1\}^m \rightarrow \{0,1\}^n$. Just sample $n$ bits for the output, and keep a log so that all future queries are consistent.


texts:
As shown in Why does my SSH private key still work after changing some bytes in the file? a typical RSA private key file contains.

  The public modulus $n$ and exponent $e$;
  The private exponent $d$;
  The prime factors $p$ and $q$ of $n$;
  The "reduced" private exponents $d_p=d\bmod(p-1)$ and $d_q=d\bmod(q-1)$;
  The "CRT coefficient" $q_{\text{inv}}=q^{-1}\bmod p$.

Looking at his annotated file I see

$e$ is negligible in size
$d$ is roughly the same size as $n$
$p$ and $q$ are each half the size of $n$
$d_p$ and $d_q$ are similar in size to $p$ and $q$
$q_{\text{inv}}$ is roughly the same size is $q$

Overall the parameters stored in the file seem to be just over 4.5 times the size of $m$.

From the RSA key generation process we can clearly see that all you really need to store are $p$, $q$, and $e$. All the other parameters can be derived from them. This results in a keyfile that is only slightly larger than $m$.

Now for the question:

Has anyone specified a format for storing such a "compact" private key and/or produced tools for converting between compact and regular keys?


texts:
I need to encrypt transmission between my device (with AVR processor) and base. I create packet data - it will be encrypted into string:

PacketData {
  int packetN;
  string data;
  CRC16 checksum;
  string nextKey;
}

As you can see, key will be changing after each packet.

First, I tried to use XOR encryption, but I forgot that if attacker know plaintext, all encryption will be without sense.

Now, I have an idea - first, use RC4 on data with key, and XOR result with same key. I see bad side of this solution - key will be same for both operations, and I want key length ~64 bits. Handshake will be written on device (8 characters), and connection will be made when base sends encrypted packet with handshake. Also, data size will be usually between 4 and 32 bytes, sometimes more.

Is this encryption give me sufficient safety? After reading about RC4 in WPA, I see that is problem in WPA implementation. Maybe I should use (when connected) two keys, for RC4 and XOR, both sended in encrypted packet?

Please, tell me what do you think about it. It must be light solution (because tiny processor) so I can't use AES. My solution is right?


texts: Can one encrypt a series of computation?

texts:
Normally when one speaks of encryption, it refers to encrypting data. Recently, a client requested a proprietary algorithm be executed on the client-side, in public web browsers. The input data would also contain other users' privacy information. Is it possible (and maybe practical) to encrypt (not just obfuscate) the data, source code, and execution of an algorithm, out in the open?

While one may perform clever operations on (simply) encrypted data, I would imagine it not possible to encrypt the execution itself, or else there would be no software cracks. But perhaps there are recent research breakthroughs?

My knowledge in cryptography is slightly above layman-level.


texts: Why is Merkle-Damgård construction insecure?

texts:
I've been reading about SHA-1. I read that SHA-1 is insecure as it uses the Merkle-Damgård construction and the Merkle-Damgård construction is — according to Wikipedia — susceptible to a variety of attacks. However, I have not been able to come up with a single example of how these work.

Can someone give me an example of a length extension attack?


texts: I know for a fact that DES is not a group, but are any of the Triple-Des versions a group? Why, or why not?


texts:
Why Static RSA and Diffie-Hellman cipher suites have been removed in TLS 1.3?

How keys can be exchanged then?

https://tools.ietf.org/html/draft-ietf-tls-tls13-28


texts: Calculating ECDSA Private Key From Multiple Signatures With Shared k (random nonce)

texts:
I've been experimenting with ECDSA signatures and with how the Sony PS3 private key was leaked. Specifically where:
$$k = \frac{z_1 - z_2}{s_1 - s_2}$$
$$d_A = \frac{z_1s_2 - z_2s_1}{k(s_1 - s_2)}$$
In my case I have two (and more) ECDSA signatures that have the same $r$ and $k$, but have a differing $s$ and $d_A$.  Although I know that $k$ is the same for all the signatures, I do not know the value of it - just that it is identical in each case.
Therefore, I have the values of the following:

$r$ for each signature (an identical $r$ for all)
$s$ for each signature ($s_1$, $s_2$, etc.)
$z$ for each signature ($z_1$, $z_2$, etc.)

I know that:

$k_1$ = $k_2$ = $k_3$, etc., but I do not know the value of it

I do not know:

$d_A$ for any of the signatures

Is it possible to calculate the value of $d_A$ for each of the signatures by using:

The known shared $r$ value,
The unknown, shared $k$ value,
The known individual $s$ ($s_1$, $s_2$, etc.) values, and
The known individual $z$ ($z_1$, $z_2$, etc.) values?

I should also add that I do also have the public key $Q_A$ for each signature but don't believe this would be of value in the above calculation.
Note: Apologies if the parameters I have used are non-standard.  I've tried to use those from the ECDSA page on Wikipedia but am working from the Sony paper which uses different letters for the parameters.
How this question differs from existing question with answer on site
This similar question has two answers which are (seemingly) contradictory.  The first (and accepted) answer states that it is not possible using the information that is given.  The second answer states that it is possible.
My question differs from this question because in mine, $k_1 = k_2 = k_3$ (etc.).  Whereas in the referenced question $k$ is unknown and is not known to be equal for $x_1$ and $x_2$ (the private keys referred to in that question).
Tried So Far
I've so far tried using an article by Andrew Corbellini that states the following:
$$k = (z_1 - z_2)(s_1 - s_2)^{-1} \bmod n$$
$$d_A = r^{-1}(sk - z) \bmod n$$
However the answer that it's yielding is incorrect for any of the signatures.
Using Gaussian Elimination
Reading this paper about key leakage with ECDSA issues, I came across section 4.3 which talks about nonce reuse across different keys and the use of Guassian elimination to calculate any of the private keys.
Consider that I have the following 3 messages that share both $k$ (unkown but equal across all three) and $r$ (known and equal across all three), with known individual $s_n$ and $z_n$ values:
$$s_1 = k^{-1}(z_1 + rd_{A_1})$$
$$s_2 = k^{-1}(z_2 + rd_{A_2})$$
$$s_3 = k^{-1}(z_3 + rd_{A_3})$$
Or rearranged to look at it with $z_n$ as the focus we get:
$$\begin{array}{rrrrr}
s_1\,k&-r\,d_{A_1}&\equiv&z_1\pmod p\\
s_2\,k&-r\,d_{A_2}&\equiv&z_2\pmod p\\
s_3\,k&-r\,d_{A_3}&\equiv&z_3\pmod p\\
\end{array}$$
Can any of the $d_A$ private keys be calculated?


texts: FPE current state of art for "small" domains

texts:
Is there any survey with the state of art treatment of format-preserving encryption for small domains (i.e. 2^20 for example)? I believe that Stalling's and Rogaway's surveys are out of date due to recent attacks on Feistel networks over small domains. Is it true that currently there is no working provably secure efficient solution for this task?

OK I just have dived into the literature, and there are a few things which I found (maybe it would be useful for others):

It is true that 10 rounds for FF1 and 8 for FF3 are not enough to hide some statistical dependencies. Maybe more rounds would save the situation.
There are some specific attacks on FF3 tweak schedule. It can be fixed easily.
There are some interesting algorithms for tweakable block cipher (FEA-1, FEA-2) with arbitrary domains of type {0, 1}^n. Combining this cipher with cycle walking technique could work. But there is a lack of analysis of these new type of primitives, and attention from the community is required.

So currently there are NO provably secure algorithm for FPE on "middle-sized" domains ~2^20 - 2^50 (FEA-2 is an exception, but there were very little attention to this kind of primitive)


texts: Why is there the option to use NIST P-256 in gnupg?

texts:
I am surely not an expert on the field , but I heared some people say that NIST P-256 is somehow backdoored .

I don't know about the seriousness of this claim . Maybes it is just some conspiracry theory . But if there is some truth about it , then why is it still implemented ? Almost everyone I asked saied it is a bad idea to use P-256 . If true :

Why is it still in GPG ( as of 2017 ) .
Does it have any use ( expect legacy & compartibility ) ?
Is it really broken to the point where it is unsafe to use ( in a professional environment )


texts: Does it matter how the IV and XOR are applied for a single AES-128 block?

texts:
I want to encrypt 128 bits of data. I understand the problem with ECB, so I generate a 128-bit Initialization Vector to use for encryption and send with the encrypted data. Is there a "best" way to apply this IV?

The Block Cipher Modes of Operation can use the IV in a couple of ways:

The IV is XOR'd with the payload, then this is used as the plaintext for AES, then the AES output is the ciphertext.
The IV is the plaintext for AES, and the output is XOR'd with the payload, then this is the ciphertext.

My system is not concerned with a stream of data, only a single 128-bit block. The receiver can never be expected to have received a prior 128-bit message. So, the modes of operation (CBC, CTR, GCM, etc.) are not fully applicable.

Are each of these functionally the same for that single block? Instead of applying the IV "before" or "after" as above, what if I XOR'd the key with the IV?


texts: TLS: Is Integrity assured when using NULL cipher

texts:
In specific implementation we're using TLS 1.0, open ssl 0.9.8 but i'm referring to RFC 5246.

For performance reasons, I'm being asked if we can use TLS without encryption.  The hope is that the perfomance cost of using TLS will be less.  The implementation will retain authentication and integrity of communication, but there will be no confidentiality.

The RFC does seem to say in Appendix C that where we see 'SHA' in a cipher suite we should understand HMAC-SHA1.  So I'd interpret the NULL_SHA in e,g, TLS_RSA_WITH_NULL_SHA as HMAC-SHA1 rather than a digest.  In Section 6.2.3.1 we see that even with a NULL cipher a mac can be calculated.  So in theory we can get integrity from TLS without encryption.

However, nobody seems to be using TLS this way, existing TLS tools (e.g. socat, openssl in default configurations) do not seem to want to negotiate null ciphers,

So my questions

Can TLS assure authentication and integrity with a NULL cipher ?  Is this a reasonable optimisation to make, it seems to hold water but i'm not confident..
What is this optimisation likely to be worth ?  The SHA must still be computed and HMAC'd even if AES-CBC is no longer calculated.  I'm not sure how SHA compares to AES, can someone estimate what % reduction in operations there will be to calculate TLSCiphertext ?  e.g could be we expect a 50% reduction in an SSL_write / SSL_read comapred to a TLS session with AES 256 encryption

Then some less important questions

the cipher suites in the RFC dont include a NULL cipher is the
NULL cipher  e.g. there's no DHE_RSA_NULL_SHA.  Openssl headers e.g. tls1.h does provide for a lot of cipher suites with NULL ciphers which dont figure in the RFC.  However, they dont get built into the configuration on my platform which may indicate this is not a normal things to use.  Similarly tools like socat dont seem to negotiate cipher suites with null ciphers..  So I'm wondering if interoperability wise this kind of optimisation is thin ice even if the eco-system is partly controlled.
There's a load of stuff that doesnt get defined in the RFC, like what the possible values are for SecurityParameters.mac_algorithm, validating the MAC on incoming message.  People implementing TLS have a more detailed standard or am i missing something ?


texts: Is computing majority element while doing secure two party computation for inner products ( input of the two parties ) an attack on the protocol?

texts:
This was told to be an attack.

However, we can create a simulator in the ideal world which sends all 1s to the trusted party and receives the number of ones of the honest party. Is this simulation correct?


texts: Why can't we use the IDEA's decryption rule for decrypting a block on CTR mode?

texts:
Suppose that a block is ciphered with IDEA using CTR mode operation. To get
 the original message, why can't we use the cyphered rule?


texts: zkSnarks - why isn't PCD more widely used?

texts:
I've been reading the paper Scalable Zero Knowledge from Cycles of Elliptic Curves, which elegantly solves (what seems to me) the main problem with zkSnarks; namely that performing non-trivial computations requires building enormous arithmetic circuits. The authors do this by showing how to compose verified computations via circuits that verify the proofs generated by other circuits.

My question is why this technique doesn't appear to be getting much use. Is the overhead from the proof-verifying circuit the main reason? I understand that vnTinyRam (the verifiable simulated CPU they introduce in the paper referenced) executes instructions very slowly, but is this because of the generality of the simulated CPU or is the overhead inherent in the PCD approach?


texts: How do digital certificates work, and why is it not possible to reverse engineer one from a signed file?

texts:
Digital certificates are used quite commonly these days, for signing files. They are used by various operating systems to ensure reliability and security. For example, Android requires that each of the apps submitted on the Android Market is signed with a certificate, and any updates are signed with the same certificate. This prevents anyone who hacks the account from replacing the application with their own, possible malicious one.

My question has two parts:

How do these certificates actually work? Is it similar to how digital signatures work?
Why is it impossible to reverse engineer and create the certificate from a file that has been signed with it? Would the answer change if you have both a signed and an unsigned copy of the same file? Does this vary on an algorithm to algorithm basis?

To simplify, let's say that our certificate has been generated by the key tool in the Java JDK, uses the RSA algorithm, has a key size of 2048 bits (does this matter?) and has a validity of 10000 days.


texts: Measuring entropy for a ciphertext only attack

texts:
When bruteforcing a password (e.g. the common attacks on DES), where you have ciphertext only, you need a way to assess whether a decrypted plaintext is the right one.  I believe the EFF DES machine does this by checking if the chars are printable.  Of course, this only works for ASCII files, not things like images.

I'd like to measure the entropy (observed 0th order byte level) and see if it's above a threshold that can be attributed to randomness.

Is that a good method?
Is there another well known method?
Where can I find tables that indicate given a randomly generated message of size X, there's p probability that it's entropy would be < ? (These types of tables are used, for instance, in chi-squared testing)

In response to D.W:
I have 5 ciphertexts all of 1 KB and no information about them.  I was able to decrypt one by dictionary attack; it is plaintext ASCII.  I imagine the others are also.  If that were the case, it's easy to automatically distinguish valid decrypts from nonvalid (check that all chars are printable, not < 0x20 or > 0x80).  Of course, the others might not be ASCII files, but until I try, I have no way of knowing.

But, I'm interested in this method in general.  For instance, when looking at a sample output of an unknown cryptosystem, it would be a good way to assess if there are any obvious statistical problems.  Or, when reverse engineering binary applications, and looking at data, and trying to assess if it's binary data or encrypted.  I also find the question mathematically of interest even aside from applications.


texts: How does the encryption/decryption process work?

texts: I am not referring here to the process of Public Key exchange, but rather the process of encryption or decryption itself after the Public/Private keys have been generated. For instance, using Diffie-Hellman algorithm we ended up getting both Public and Private Keys of size 512 Bytes. How are we supposed then to use the Public Key to encrypt a given plain text message "Hello World!" and the Private Key to decrypt it?


texts: Which public-key cryptosystems are used the most?

texts: Does anybody know if there is some kind of measure on how often public-key cryptosystems like El Gamal, RSA,... are implemented. Which ones are most common?


texts: Prove that a given encryption scheme is perfectly secret

texts:
I'm studying for an upcoming test and I can't figure out the following sample question:

  Let $\Pi = (\operatorname{Gen}, \operatorname{Enc},
 \operatorname{Dec})$ be an encryption scheme with key space $\mathcal
 K$, message space $\mathcal M$, and ciphertext space $\mathcal C$
  where $\mathcal K =\mathcal M =\mathcal C = \{0, 1, 2, 3\}$. Algorithm
  $\operatorname{Gen}$ returns a uniformly random key $k$ in $\mathcal
 K$. For any key $k$ in $\mathcal K$ and any message $m$ in $\mathcal
 M$, $\operatorname{Enc}(m)$ using key $k$ is defined as $(m + k) \bmod
 4$. For any key $k$ in $\mathcal K$ and ciphertext $c$,
  $\operatorname{Dec}(c)$ using key $k$ is defined as $(c - k) \bmod 4$.

  a) Prove that $\operatorname{Dec}(\operatorname{Enc}(m)) = m$ using
  key $k$ holds for any key $k$ in $\mathcal K$ and any message $m$ in
  $\mathcal M$.

  b) Prove or disprove: $\Pi$ is perfectly secret.

The formal definition of "perfectly secret" used is:

  An encryption scheme (Gen, Enc, Dec) over a message space $\mathcal M$ is perfectly secret if for every probability distribution over $\mathcal M$, every message $m$ in $\mathcal M$, and every ciphertext $c$ in $\mathcal C$ for which $Pr[\mathcal{C} =c] > 0: Pr[\mathcal{M}=m | \mathcal{C}=c] = Pr[\mathcal{M}=m]$.

In this scheme, keys can be reused.


texts:
In some literature it is written that the private key should be chosen random from

{2,3, ..., p-1}

and in some it says

{2,3, ..., p-2}

I guess p-1 is a weak private key, but why is that so?
The calculation would be:

A = k pub, A = αp-1 mod p


texts:
Given plaintext: P[i], i = 1..N

Given stream of cryptographic numbers S[i, j], i = 1..N, S[i, j] in [1, j] generated by RC5 for example

We encrypt using Fisher-Yates shuffle algorithm:

for (int i = N, i > 1 ; i--) swap(P[i], S[i, i])

How to estimate complexity of breaking such chipher?

Is it lower than strength of S[i] generator?

How does it depend on value of N?

How does it depend on data we encrypt?

Unfortunately I was unable to find anything useful on topic.

P.S. Why not AES? Because chipertext is harder to detect using frequency analysis.


texts: Is a simple stream cipher "partially homomorphic" if no integrity check is applied?

texts:
My understanding is that, simply put, a stream cipher is just a CSPRNG such that $R(i,k)$ will produce a deterministic but statistically random sequence, where $i$ is an IV, and $k$ is the session key. The resultant key-stream $K$ is then combined with plaintext (i.e. $C = K \oplus M$).

Now, if we take two messages $m_1$ and $m_2$, and assume $\mathcal{E}(x)$ and $\mathcal{D}(x)$ are functions that encrypt and decrypt a message as described above, surely the following is a partially homomorphic cryptosystem?

$$\mathcal{D}(\mathcal{E}(m_1) \oplus m_2) = m_1 \oplus m_2$$

This seems a really simple and fundamental way to perform unauthenticated homomorphic cryptography, yet the Wikipedia article doesn't mention it at all.

Am I incorrect in saying that this process demonstrates homomorphism?


texts: What is this EC key derivation method called?

texts:
I'm looking to identify the EC key derivation method used in Hyperledger Fabric. I can't find anything in the docs or the protocol specs, but the functions' code is here for the private key and the public key.

The derivation function seems to be very simple, DerivedPrivate = MasterPrivate + (k+1) and DerivedPublic = MasterPublic + (k+1) * G all mod N with k being a random derivation data. And yet, I don't seem to be able to find the name or the source of this method.

I'd like to know about the patent and copyright status of this derivation method, and to do that I need something to google for. I'm also looking for a more formal description of this method.


texts: How fast a middle-class computer can verify assymetric signatures (like ECDSA, RSA etc.)?

texts: I have an idea for a peer-to-peer network that will require every connected peer to verify many symmetric signatures per second. In bitcoin, it's the same - every peer independently verifies signatures of every transaction. How many signatures, which sign some message (ECDSA or RSA or whatever is fast and secure) can middle-class computer verify per second (I would like to predict it to know how such network could scale)?


texts: Hermitian curves introductory references

texts:
Could you give me some reference to start on Hermitian Curves. Some papers or textbooks would be perfect, and please mention if it's math inclined or comp.sci. inclined.

I've only seen hermitian curves in coding theory but if you know of applications of these curves to cryptography please let me know.


texts:
What would be the most efficient way to find two large (2048bit) integers $k$ and $q$ such that $p = kq + 1$ is prime and so is $q$?

Is there some standard algorithm that I could use?


texts: Are asymptotic lower bounds relevant to cryptography?

texts:
An asymptotic lower bound such as exponential-hardness is generally thought to imply that a problem is "inherently difficult". Encryption that is "inherently difficult" to break is thought to be secure.

However, an asymptotic lower bound does not rule out the possibility that a huge but finite class of problem instances are easy (eg. all instances with size less than $10^{1000}$).

Is there any reason to think that cryptography being based on asymptotic lower bounds would confer any particular level of security? Do security experts consider such possibilities, or are they simply ignored?

An example is the use of trap-door functions based on the decomposition of large numbers into their prime factors. This was at one point thought to be inherently difficult (I think that exponential was the conjecture) but now many believe that there may be a polynomial algorithm (as there is for primality testing). No one seems to care very much about the lack of an exponential lower bound.

I believe that other trap door functions have been proposed that are thought to be NP-hard (see related question), and some may even have a proven lower bound. My question is more fundamental: does it matter what the asymptotic lower bound is? If not, is the practical security of any cryptographic code at all related to any asymptotic complexity result?


texts: Recover plaintext from truncated ciphertext using AES for FPE

texts:
I am trying to implement an FPE for a 19-digit long number. I am trying to follow the lecture of Prof. Dan Boneh and here is how I understand it:

Get the nearest power of two greater than $10^{19} \rightarrow 2^{64}$,
Get the binary representation of the 19-digit number,
Split the 64-bit long binary representation into two 32-bit for Feistel network,
Perform 7 rounds of Feistel network with AES (PRF),

pad zeroes to left of 32-bit until 128 bits for AES,
truncate cipherText obtained to the 32 Least significant bits for Feistel XOR and next rounds,

Convert the output of the Feistel network to Decimal and check if it is in the range of $0 - 10^{19}$ (some values are between $10^{19}$ and $2^{64}$), if not perform Feistel on the cipher text until it is within the range.

I am trying to do pad-encrypt-truncate for step 4 but I was not able to recover the plaintext from the truncated ciphertext. I am doing these decrypt steps right now:

Pad zeroes to the left of the 32-bit ciphertext (truncated) until 128-bits,
Decrypt using AES,
Truncate to Least Significant 32 bits (this is different from the ciphertext).


texts: ECC: application of multiple multiplicative inverses

texts:
I've recently read about "Montgomery trick" on Application of Montgomery's Trick to Scalar Multiplication by Pradeep Kumar Mishra and Palash Sarkar which provides a way to compute several multiplicative inverses at once using this technique:
if x = 1/(ab), then 1/a = xb and 1/b = xa

I've also analyzed various algorithms for computing multiplicative inverse on Modular Inverse Algorithms without Multiplications by Laszlo Hars.
At the top of the page 12 they briefly mention:

Still, in case of elliptic curve cryptography the most straightforward
(affine)   point representation and implementation of the point
addition is the best (the projective, Jacobian and Chudnovsky-Jacobian
coordinates are slower, see [8]).
T

Of course, projective coordinates usually using delayed inverse, but more multiplications per point addition.
Affine coordinates need less total operations, but inverse is calculated at every point addition instead of once at the end.
As I understand, Montgomery trick can eliminate a computation of inverse at every step.
However, I struggle to understand how to apply this technique.
Let's say I have 4 points in affine coordinates on some weierstrass curve.
Affine addition formula requires an inverse of X-coordinate difference between two points. Which means that I can't add all 4 points together with only one inversion.
I could do P1+P2 and P3+P4 with one inversion, but then I need to add P1,2 together with P3,4, which means that another inversion is needed. So at the end it is slower than using projective coordinates, if inverse cost compared to multiplication is high.
I understand how to apply "Mongomery trick" to a case where we calculate a bunch of independent scalar multiplications at once, and then convert all resulting points to affine system using only one inverse. But I don't understand how to use it in a single multiplication which consists of many additions, and if this even possible at all.


texts: Reusing characters from plaintext in salt

texts:
I'm curious about the security implications of reusing characters from the plaintext as salt.e.g.

$salted_plaintext = $plaintext[1] . $plaintext[7] . $plaintext;

My gut feeling is that it increases security through obscurity, though not as much as a proper salt, as existing rainbow tables wouldn't be applicable and would have to be re-made with this "salt" in place.

Since I'm sure someone will ask: the hash is for comparison of some sensitive data against a list of stored hashes.


texts: Determine if encryption is safe against CPA

texts:
The following encryption scheme encrypts each block of length $n$ of the plaintext separately:

$c_i = k_1 \oplus F(k_2 \oplus p_i)$

Where $F$ is a strong pseudo-random permutation (i.e. it is easy to calculate $F(.)$ and $F^{-1}(.)$), and $|k_1|=|k_2|=n$.

  $a.$ Is this encryption safe against a CPA attack with a single block? multiple blocks?

  $b.$ Show an efficient attack to discover the two keys.

So I thought of choosing $p=0$, and then we easily get $k_1 \oplus F(k_2)$, and we can do the same with $p=1$. But then we have two equations with our two variables being $k_1$ and $F(k_2)$, so we can get $k_1$, but how does that help with $k_2$ if we cannot calculate $F^{-1}$?

Am I in the right direction? Any help would be appreciated.


texts: Practical multivariate quadratic FHE – how does it compare to other FHEs?

texts:
Came across this startup claiming practical FHE and then their blog post going into some additional details on it.

It was my understanding that practical FHE is still years/decades off. They said back in September 2015 that they would publish the details of their FHE cipher which they call “KFHE”, but it appears that the details still have not been released (as of June 2016). They have released the source code for their KFHE implementation, however. From it, it appears they are using multivariate quadratic FHE.

What is multivariate quadratic FHE and what is unique about this FHE compared to previous attempts? How does this hardness assumption compare to others that have been previously used in building FHE?


texts: Discrete Logarithm: Given a p, what does it mean to find the discrete logarithm of x to base y?

texts:
My understanding is that $a^b \bmod p$ is the discrete logarithm problem. Given the question is worded this way, are we trying to find $ \log_y x \bmod p$.

For instance, if we are trying to compute the discrete logarithm of 3 to base 2 - given that $p=11$, what would be the output (or the equation)


texts:
I understand the pepper concept of adding but not storing a secret and iterating through the set of possible secret values for verifying.

But is pepper also useful when it comes already to the use of key stretching algorithms?

Key stretching is used to make a (possibly) weak secret more robust against brute force attacks by increasing the validation time. The pepper method has the same purpose. Does it make sense to combine this techniques? Following the important security principle keep it simple, I would expect that e.g. stretching a password with PDKDF2 and a higher iteration value is better than combining pepper and PDKDF2. Is this assumption correct or do I miss an important aspect? Thx.


texts: Why is H(message||secret_key) not vulnerable to length-extension attack?

texts:
Given a Merkle-Damgård hash function $H$, I know that an attacker can forge a message protected by a MAC computed as $H(\textrm{secret_key}||\textrm{message})$.

Why can't he perform the same extension attack on a MAC construction $H(\textrm{message}||\textrm{secret_key})$?


texts:
I'm pretty new to the whole cryptography scene, so please forgive me if I make any incorrect statements.

I have a 16MB image that I'm encrypting and authenticating using AES-GCM. I obtain a 16MB encrypted image and a MAC. From what I could tell, this should provide me both confidentiality, authenticity, and integrity. I might be wrong on this.

With that said, is it even necessary to perform ECDSA signing on this encrypted image? I understand that the purpose of ECDSA is to provide authenticity from the person who provides the ciphertext, but since the encrypted image was already authenticated via AES-GCM, this seems like a redundant option.


texts: Are there any high level memory-hard PBKDF constructions?

texts:
The PBKDF2 construction from PKCS #5 v2 has the convenient feature that it can be implemented using only standard interchangeable cryptographic primitives.  Specifically, it only requires the availability of a suitable PRF, typically implemented using a standard cryptographic hash function via HMAC (another high level crypto construction).  Thus, PBKDF2 can be easily implemented on top of any crypto library that provides access to a suitable hash function, even if the library does not directly implement PBKDF2 (or even HMAC) itself.
However, while PBKDF2 implements an adjustable work factor (in the form of an iteration count) to thwart brute-force password cracking attempts, it uses only a fairly small amount of memory.  This leaves it vulnerable to attacks using parallel computing hardware such as GPUs, FPGAs or dedicated ASICs.
In recent years, several "memory-hard" password-based key derivation functions, such as scrypt and Argon2, have been developed to address this issue.  These functions, however, all tend to use specific non-standard primitives that are not (yet) implemented by many crypto libraries, and which would be hard if not impossible to implement securely and efficiently from scratch in a high-level programming language.
Thus, my question would be: Are there any memory-hard PBKDF constructions that can be implemented using only common standard crypto primitives, like (generic) hash functions and/or block ciphers?
Ideally, the security of the construction should be easily reducible to reasonable security assumptions on the underlying primitives.  I do suspect that for some aspects (particularly, the memory-hardness) this reduction may be non-trivial, but hopefully still provable.
Also, to be well suited for implementation in high-level languages, the construction should ideally be implementable using only a relatively small number of high-level calls to the underlying crypto library.  For example, a construction based on a block cipher should ideally spend most of its time running the cipher on bulk data in a widely implemented mode of operation like (bulk) ECB or CBC, instead of requiring repeated high-level calls to encrypt individual blocks.  Similarly, for hash-based constructions, it would be ideal for most of the hash invocations to be on fairly long input strings.  (Note that PBKDF2-HMAC fails this additional requirement, invoking the hash repeatedly on short strings.)

Ps. This earlier question is a good example of the kind of use case for which such a construction would be useful for:

"I am restricted on a certain environment involving PHP and am currently unable to implement new memory hard hashes such as scrypt (and I am not trying to compete with the likes of scrypt).
My current key derivation is simply an iteration of HMAC (password + salt). But it seems that using AES or other encryption ciphers, one could construct a fairly simple, memory-hard key derivation function using build-in PHP capabilities such as HMAC and AES encryption (assuming PHP is compiled with openssl support)."

Alas, their proposed construction does not actually seem to be memory-hard.  I've been thinking about possible alternative constructions to achieve the same goal, but before investing a lot of time and effort on analyzing their security and memory-hardness, I thought I'd first ask whether this is already a solved problem.


texts: The Rationale behind NIST's counter/LFSR recommendation on deterministic IV constructions on SP 800-38D

texts:
The NIST has a "SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC". This guideline is a base for AES-GCM from definition to security considerations. ( all bolds are mine)
In section 8.2.1 Deterministic Construction IV

In the deterministic construction, the IV is the concatenation of two fields, called the fixed field and the invocation field. The fixed field shall identify the device, or, more generally, the context for the instance of the authenticated encryption function. The invocation field shall identify the sets of inputs to the authenticated encryption function in that particular device.

and later in the same section

The invocation field typically is either 1) an integer counter or 2) a linear feedback shift register that is driven by a primitive polynomial to ensure a maximal cycle length. In either case, the invocation field increments upon each invocation of the authenticated encryption function.

The distinction of a counter and Linear Feedback Shift Register (LFSR) is clear. A counter can be simply implemented in the CPU registers in construct an LFSR that requires a primitive polynomial and extra code. Selecting/finding a primitive polynomial is not hard today. As listed in this SO answer there is a report from HP list the binary primitive polynomial of low-degree. One can also use Maple, Mathematica, and SageMath to find one.
If everything works correctly, the counter and LFSR can produce unique IV's that are crucial for the security of the AES-GCM. Any (IV,Key) pair use can remove the confidentiality and can cause forgery.
There is one problem that I'm aware of; during the system failures, the last incremented/advanced counter/LFSR value can be lost. If the administrators continue from the last known values this can result in (key,IV) pair reuse. To mitigate either exchange a new key or use random in some part of the IV.
In the comment of the answer of What are the rules for using AES-GCM correctly?
Maarten Bodewes said

Sorry, but I don't understand why you'd need a LFSR specifically rather than a generic DRBG.

and also
Gilles 'SO- stop being evil' said

This is good advice except for the LFSR. A non-cryptographic RNG has no place in crypto code.

and

I wonder why they suggest an LFSR. It's a pity that they don't give a rationale.

So the questions for the AES-GCM are;

What is the rationale of the NIST to suggest counter and LFSR for IV.

Why using an LFSR is not good advice?

In section 8.2.2 RGB-based construction talk about RGB(Random Bit Generator) in two ways

an output string of r(i) bits from an approved RBG with a sufficient security strength, or
the result of applying the r(i)–bit incrementing function to the random field of the preceding IV for the given key

Is there any advantage of RGB against counter/LFSR?


texts:
Before stating my questions, let us recall the REACT transform [OP01], which enables to construct a CCA-secure hybrid PKE scheme, $\varepsilon'_{pk}$, from an OW-CPA PKE scheme $\varepsilon_{pk}^{asym}$, an IND-secure symmetric encryption scheme $\varepsilon^{sym}$, and hash functions $H$ and $G$. The transform works as follows:

$c_1 = \varepsilon_{pk}^{asym}(R), c_2 = \varepsilon_{K}^{sym}(m)$, where $K = G(R)$ and $R$ is chosen at random.

Then $\varepsilon'_{pk}(m) = (c_1, c_2, H(R,m,c_1,c_2))$

My questions are: Why is it necessary to include $c_1$ in the hash $H$? What would be the consequences of dropping it from the hash (i.e., $\varepsilon''_{pk}(m) = (c_1,c_2, H(R,m,c_2))$? I guess that the main reason is to achieve non-malleability, but is it possible that by dropping it we obtain a transform to Replayable CCA (RCCA) security [CKN03]? Informally, RCCA was like CCA security “except that they
allow anyone to generate new ciphertexts that decrypt to the same value as a given ciphertext” [CKN03]. Since we are including $m$ in the hash, we can guarantee that the original message is preserved, but we allow modifications on $c_1$.

I am asking this because I'm interested in schemes where a certain degree of malleability is permitted. In particular, re-encryptions of the original ciphertext are permitted, as long as they decrypt to the original message.

References:

[OP01] Okamoto, T., & Pointcheval, D. (2001). REACT: Rapid enhanced-security asymmetric cryptosystem transform. In Topics in Cryptology—CT-RSA 2001 (pp. 159-174). Springer Berlin Heidelberg. $\rightarrow$ PDF
[CKN03] Canetti, R., Krawczyk, H., & Nielsen, J. B. (2003). Relaxing chosen-ciphertext security. In Advances in Cryptology-CRYPTO 2003 (pp. 565-582). $\rightarrow$ PDF


texts:
Why did we call it digital signature if an attacker can pretend to be Bob?
Bob hashes his message, encrypts the hash with Alice's public key, and sends it to Alice with the original message. Alice receives that message and the signature. She decrypts the signature with her private key, and compares the outcome with the hash of the message.
But why did we call it a signature if a hacker can do what Bob has done?
A hacker can also hash his message, encrypt the hash with Alice's public key and send it to Alice. Sorry guys but digital signature seems similar to asymmetric encryption to me, a hacker can also pretend to be Bob.


texts: Symmetric encryption using RSA for random generated password

texts:
I'm fairly new to encryption, so I wanted to check the logic for a .net solution I'm working on that encrypts data between two parties. the receiving (decrypting) party will have an RSA key pair stored. They will transmit the public key to the encrypting party via a web service call. The encrypting party will use the public key to encrypt a random generated password. Prior to the RSA encryption, this password will be used to derive the Key/IV (using Rfc2898DeriveBytes) for RijndaelManaged symmetric encryption for the main data.

The RSA-encrypted password will be transmitted along with the RijndaelManaged-encrypted data via another web service call. The receiving party will decrypt the RSA password using their private RSA key. They will then use the password to decrypt the RijndaelManaged-encrypted data.

The thinking is that the use of the random password will avoid the pitfalls of storing a constant password if I were to only use symmetric encryption. It also provides for a different key/IV each time as well as a different RSA key each time. The reason I'm thinking of this Symmetric/Asymmetric hybrid approach is after reading about some of the performance pitfalls of just using RSA. My question is whether this is any better or worse than going with one encryption method or the other, or if I'm missing something that will make this approach impossible or open me up to some sort of vulnerability.


texts: Using Diffie–Hellman without a key derivation function

texts:
In an answer to another question, it was suggested that the shared secret derived from Diffie–Hellman key exchange could then be used directly as a one-time pad to encrypt a message (by XORing the message with the shared secret after writing everything in binary). This forms a simple hybrid cryptosystem.

User fgrieu writes in the comments that this has a flaw, saying:

  "you may use its resulting shared secret as a one-time-pad": but this
  less than satisfactorily secure! If one simply XORs the message with
  the shared key and sends the whole result, then it is possible to
  recognize which of two messages was sent with probability sizeably
  better than random. There is a similar issue with ElGamal encryption.
  Problem is: in $\mathbb Z ^*_p$, Diffie–Hellman leaks the Legendre symbol of the
  shared key. That's one reason we stick a key derivation function on
  top of DH.

Recall that the Legendre symbol determines whether an element of a group is a quadratic residue.

Could we fix this by choosing an element $g$ that generates a large subgroup, all of whose elements are quadratic residues? Concretely, we could take $p= 2q + 1$ for a large prime $p$ and then find an element which generates the order $q$ subgroup.

Now, if Diffie–Hellman is done with this group element, any eavesdropper knows the lowest order bit of the shared secret. So I could just remove this bit and use all the higher order bits as the one-time pad, and no information about the shared secret leaks.

Is this scheme secure, assuming an eavesdropper can't break Diffie–Hellman? Even if the particular flaw fgrieu points out is fixed by this scheme, are there other compelling reasons to combine Diffie–Hellman with a key derivation function?

The Wikipedia page for Diffie–Hellman notes that IKEv2 chooses the public group element this way. However, they do not say whether a further key derivation function is applied.


texts: ElGamal on elliptic curves attack model (CPA,CCA1,CCA2)?

texts:
I can't find relevant literature discussing three attack models of the ECC-ElGamal algorithm (CPA, CCA1, CCA2)
ECC-ElGamal algorithm: ElGamal with elliptic curves
I only know that ElGamal belongs to CPA, but I can't determine which one (CPA, CCA1 or CCA2) belongs to in the case of ElGamal on ECC.
It would be better if there is a source of relevant literature!!! Thank you very much!!


texts: How to provide secure "vanity" bitcoin address service?

texts:
Bitcoin addresses are RIPEMD-160 hashes of the public portion of a public/private ECDSA keypair (along with an abbreviated hash of the hash to provide a check code, as @pulpspy notes in a comment).  They are generally base-58-encoded.  See Address - Bitcoin

In Vanity bitcoin addresses: a new way to keep your CPU busy, user "ByteCoin" says he can create and sell "vanity" bitcoin addresses (like 1ByteCoinsUNJun4KL3HSt1NfFdXpzoRTy) for people.  Furthermore, he states he can use a handshake algorithm to do so without actually getting access to the associated private key (and thus without being able to spend bitcoins which are sent to the address).

What is a fast algorithm for creating vanity bitcoin addresses?  Can they in fact be created and sold in a secure way?


texts: SHA-512 - How difficult is it to find a hash digest beginning with at least twelve zeros?

texts: I know it's possible to find a hash value with multiple zeroes in it, I know of some BitCoin hashes with it, but how difficult is it to find/create a hash digest with 12 or more leading hex zeroes in it?


texts:
In ε-differential privacy, what does the ε refer to?

Is it privacy value or the notation used?

Can anyone provide an example of differential privacy?


texts: Key Distribution Center Key Protocol Analysis

texts:
As shown in the image, why is Circle 1 to be B and Circle 2 to be A?

Why is not the opposite, that is, Circle 1 to be A and Circle 2 to be B? like this picture

From my understanding, Notation B in 2nd picture is used to prevent from reflection attack. So in the 1sst picture, isn't that arrangement cannot prevent from reflection attack?


texts: Can I base a public-key cryptosystem only on a hash algorithm?

texts:
Could I base a public and private key system on just using a hashing algorithm? For example:
privKey = sha256( randomGenerator() )
pubKey = sha256( privKey )

Why do I need to use different algorithms? For example, RSA or ECC?


texts: How to generate an El Gamal signature without knowing the private key x?

texts:
Let $x$ be the private key.
Let $k$ be a random generated number $< p-1$, with $p$ the large prime.
Let $g$ be the generator of $p$ the large prime.
Let $r$ be the equality $r=g^k$
Let $m_e$ be an oridnary message.
Let $s$ be the signature $s=k^{-1}[m-rx] \bmod p-1$

My question is, how do we generate a valid signature $s'$ without knowing the private key $x$? The only indication I have is writing down the equality $r$ as a product $g^a\cdot y^b$ with $y=g^x$.

P.S: I don't remember how to format, so sorry if things are a little bit messy.


texts: Difference between AES CMAC and AES HMAC?

texts:
Can someone elaborate on how 'signing' is done using AES- CMAC and AES-HMAC?

HMAC Signing as I understand: Compute the HMAC( Hash the key and the input concatenated in a special way) Verification: Verify if for the given input and secret key the calculated HMAC(signature) is the same as that is computed. But how is AES used in conjunction with this? is it HMAC(AES(Data)) then what is CMAC?

CMAC signing as I understand: is to encrypt the input using the key by applying AES algorithm and then calculating  a MAC by applying a special concatenation step of the key and resulting encrypted data??. For verification, the signature should be compared with the newly computed CMAC of input and key at the receiving end.

Please clarify

Thanks.

Also, does openSSL libs support AES CMAC and AES HMAC?


texts:
The Wikipedia article on GCM says GCM can take full advantage of parallel processing.

I had thought GCM uses a random IV for the first block, then for the second block uses the results of encrypting the previous block as the IV. If this is correct, how can it possibly be done in parallel?

The question boils down to which of these statements is wrong, and why?


texts: meaning of Reduce f modulo the order of the base point G

texts: I am trying to perform some math operations related to Elliptic curve cryptography, and came across this sentence: Reduce f modulo the order of the base point G. What does it mean?


texts: Why does CTR mode become insecure after $2^{0.5 \times n}$ blocks?

texts: The question is exactly what it says on the tin. If $n$ is the block size in bits of a block cipher, then why does outputting $2^{0.5 \times n}$ block in counter mode become a problem when there is no repetition of the keystream until after $2^{n}$ blocks have been output?


texts: Statistical Tests for Pseudorandom Functions

texts:
Say I have an implementation of a potential Pseudo-Random function and I want to test whether my implementation does at least not contain any obvious flaws. As far as I understand, in other cryptographic settings, statistical tests are employed to ensure the correctness of the encryption algorithm.
What kind of statistical tests could I use for Pseudo-Random functions?


texts: Besides binary, decimal, hex, oct, are there encryption algorithms based on exotic/other numbering systems?

texts: We all know there is Base 10, Base 16, etc. Are there encryption algorithms out there based on different or unique Base-N numbering systems?