# Tag Info

7

I don't think idea 1 can be made to work at all. The main point is that in order to generate a correct secret decryption key, the key generator must know the order of $\mathbb Z^*_n$, i.e., the totient of the modulus $n$. The generator knows that $n=p \cdot q$, where it believes that $p$ and $q$ are primes, and so it believes that the totient is ...

7

The two last equations don't directly give you the value of $C_i$, they are telling you the values of the remainder of Ci when divided by $P$ and $Q$. You then use the Chinese Remainder Theorem with this information to produce the value of $C_i$ (modulo $N$) that you are looking for. See en.wikipedia.org/wiki/Chinese_remainder_theorem (there is an algorithm ...

7

Rather risk vulnerabilities of third party library than implement your own. If you feel novice on this field, only implement cryptography yourself as an learning exercise. Why: Mistakes, lack of know-how and maintenance. It is very easy to make novice mistakes in custom implementation of cryptography. Even battle scarred veterans of the field do mistakes ...

7

As @D.W. guessed, the branching program for a circuit essentially reveals the original circuit. It's not clear what you mean by "apply the whole obfuscation process to the circuit-revealing branching program," but the prospects for that do not seem good: evaluating the branching program is highly sequential (polynomial depth), and you would need to ...

7

All of your encryption rounds are incorrect, either due to incorrect round function or key schedule (or state alignment). Showing round 0 (round key addition before first round) will help show if the keys are being added correctly to the state. The key expansion is also very important, if that is not done correctly it will not work at all. I will assume ...

6

The only reason you are seeing this is because you are dealing with such small primes. With primes like we would use in practice (1024 bits), the probability of this happening is very, very small. And, it can only happen when $e>\sqrt{\lambda(n)}$. Since we typically use $e=65537$ in practice, it is guaranteed to not happen. Anyways, there is no mistake ...

5

Actually, the fundamental mathematical operation is not \begin{align} \mathbb{N} &\to \mathbb{N} \\ m &\mapsto (m^e) \bmod n & \text{(elevate to the power of $$e$$, divide by $$n$$ and take the remainder)} \\ \end{align} but  \begin{align} \mathbb{Z}/n\mathbb{Z} &\to \mathbb{Z}/n\mathbb{Z} \\ m &\mapsto (m^e) \bmod n & ...

4

As long as you're using any modern encryption algorithm (and you're using it correctly: random key, new random or unique IVs for each message, depending on the mode of operation, etc.) then you'll be fine. In fact, you'd be fine even if an attacker got to choose which plaintext you encrypted and got to see the result; this information would not help him ...

4

I am wondering if using Skein or the Keccak hash algorithm in this construction (as a stream cipher) is secure: In the case of Skein and Keccak it should be secure. However, both of those have defined their own cipher modes which you should IMO prefer. (For speed and compatibility, if not security.) The Skein one is defined in section 4.10 of the ...

4

The risks are much higher that there will be mistakes in a novice (or even advanced) implementation. Look at the history of OpenSSL. It was long thought secure, until someone discovered a timing side channel attack. How would you know your code is secure against all the vulnerabilities you don't know about?

4

If you take a close look at line 105 of the C++ implementation, you see that it subtracts delta from the sum instead of adding it: 103 for (int32_t i = 32; --i >= 0;) { 104 v0 += ((v1 << 4 ^ v1 >> 5) + v1) ^ (sum + k[sum & 3]); 105 sum -= delta; 106 v1 += ((v0 << 4 ...

4

Well, if $g$ is a generator of $\bmod\ p$ for prime $p$; that is, if all values in the range $[1, p-1]$ are possible values for $g^i \bmod p$, then we have $g^a \neq 1 \bmod p$ for any $a = (p-1)/r$ where $r$ is a prime factor of $p-1$. You select $p$ to be a "safe prime", that is $p-1 = 2 \times q$ where $q$ is also a prime. This implies that, in this ...

4

To clarify a misconception in your question: It is not true that $e$ is chosen large to make RSA more difficult to crack. Often $e$ is chosen from $\{3,5,17,257,65537\}$. This has computational advances with regard to square and multiply algorithms as mentioned by Gilles. The choice of $e$ has no influence in the security of RSA primitive (as long as ...

4

Fast software implementations of AES were proposed in a number of research papers. The state-of-the-art approach is to do a bitsliced implementation, where bits of sequential blocks at identical positions are processed at the same time. The fastest implementation described so far that does not use AES-NI instructions was designed by Kasper and Schwabe. ...

3

You could, however the one part that doesn't translate in an obvious manner is the Galois field representation; you would need to pick a field representation for $GF(2^{256})$ and $GF(2^{512})$, because those have not be predefined for those sizes. Here's the issue; GCM does field multiplications internally; that is, it takes two $N$-bit vectors (where $N$ ...

3

You don't need fully homomorphic encryption for this. In particular, you don't need to use Gentry's scheme. Any standard scheme for additively homomorphic encryption will be fine. For instance, Paillier should work fine, as should exponential El Gamal. Search this site and you can find lots of information on additively homomorphic encryption. See, ...

3

Chris's answer is great. As it does not address how one would detect #2, I'll take a stab at it. Assume there is some watchdog looking at public keys in your system, trying to detect a problem. They can easily tell if two public keys share a prime by computing gcd. A gcd of anything other than 1 would identify bad keys. So, let's assume that once two ...

3

If nothing else, it makes the output of the pool irrecoverable. One of Fortuna's goals is to make prior Fortuna outputs safe from a compromise (the discovery of all of Fortuna's current data by an adversary). If the pool continued on without a reset, with little or no entropy added before the compromise took place, the adversary could more easily calculate ...

3

0x61C88647 is the 2's complement representation of -0x9E3779B9. You can implement XTEA as: void XTEA_Encrypt(uint32_t v[2], uint32_t const key[4]) { unsigned int i; uint32_t v0=v[0], v1=v[1], sum=0, delta=0x9E3779B9; for (i=0; i < 32; i++) { v0 += (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + key[sum & 3]); sum ...

3

To answer your questions in order: You won't find test vectors for the s-boxes in the submission - the s-box functions are implementation specific optimisations, especially the bit-sliced s-box functions like the Osvik and Gladman/Simpson, which actually compute multiple s-box lookups in parallel. If you need to test your s-box implementations, I would ...

3

The most effective trapdoor I could imagine an adversary building into an RSA key generation algorithm would be the following: Preparation The adversary generates a set of RSA keys of varying sizes. The public keys will be built into the malicious key generation code, the secret keys are kept by the adversary. Key generation algorithm The algorithm is ...

3

It all comes down to your threat model, right? Just because an implementation is done in hardware does not mean that power and fault attacks must be considered. If I host the hardware in my secure facility with armed guards at the door, but the hardware is connected to a machine which is connected to the internet, I might feel that it is okay to not be ...

2

If your ints are unsigned then the code r = (r * 33) + (int)c and the fact that you're using 32-bit integers yield the equation $\;\;\;\; \text{new_r} \: \equiv \: (\text{old_r} \cdot 33) + \text{(int)}\hspace{.02 in}\text{c} \;\; \pmod{2^{32}} \;\;\;\;$. Since 33 is odd and $2^{32}$ is even, 33 is a unit mod $2^{32}$. $\:$ I used wolframalpha to determine ...

2

Am I on the right track with reversing DJB2 (can it be reversed?)? Is there some way of finding the remainder of a large number that has been modded by 232? You were on a right track to explain why it can't be easily inverted. Given an arbitrary $h_i$, every letter of the alphabet will give you another potential $h_{i-1}$ that the value was before that ...

2

What the specification is saying is that prior to processing, the message is padded to a full block length, with the empty message padded to a single block. The spec on page 4 describes the input into the algorithm as: Define $||a||_n = max\{1, \lceil|a|/n\rceil \}$, where the empty string counts as one block Let $m = ||M||_n$ Partition $M$ into $M[1] ... ... 2 As noted by izaera, that reset of the pool is explicitly specified in Fortuna, and not an implementation artifact. The pools in Fortuna are SHA-256 hashes. By definition, in order to obtain a pool's result, the SHA-256 hash must be obtained (in the present code, that's the job of sha256_done). With a standard SHA-256 implementation, there is no way to ... 2 In general there is no such recommendation. Python is quiet useful for quick prototyping, but is generally very slow. Too slow to do any expensive computations. However, you can, for instance, write you core analysis functions in c and then use them in your python analysis tools. This is actually a quiet common method of going about things. 2 The standard solution is to generate$g$and$p$once during application development, then hardcode$g$and$p$in your code. There are standard choices for$p$and$g$, e.g., documented by NIST in their FIPS series. I suggest using one of those. There is no need to re-generate$g$or$p$each time. You can use the same$g$and$p$for everyone. See ... 2 No. If you don't have a strong math background, implementing RSA yourself is a bad idea (and perhaps even if you do). There are many ways to go wrong, which can open up subtle security weaknesses. Instead, you should use a well-vetted RSA implementation from a standard crypto library, and a well-vetted protocol -- or hire a cryptographer who does ... 2 Good that we have resolved the issue (the bug is to compute$g=h^{(p-1)/q} \bmod p$instead of$g=h^{(p-1)/q} \bmod q$). When implementing such protocols you can take the following "rule of the thumb": When working with group elements of the multiplicative group$\mathbb{Z}_p^*\$, i.e., performing group operations, then you always do your computations ...

Only top voted, non community-wiki answers of a minimum length are eligible