# Tag Info

## Hot answers tagged implementation

8

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

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

No, modified algorithms they are unlikely to be harder to break, unless the changes were explicitly made by a cryptographer to make the algorithm more secure. They are certainly not any safer just because they are different. Due to the Kerckhoff principle you should assume that the algorithm is known. So changes in the algorithm in itself does not increase ...

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

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. ...

4

I add my whitebox AES implementation on GitHub in: C++ Java C++ version implements both Chow's (mixing bijections, input/output encodings, external encodings) and Karroumi's (dual AES in each column) whitebox AES scheme plus Billet's key recovery attack on both schemes. Java implements Chow's scheme only. PS: Due to low reputation I post links to ...

4

I think that there is no chance of getting such an asymmetric cipher simply because you forgot about science. The security on todays asymmetric cryptography is mostly based on the assumption that some mathematical algorithms cannot be reversed (e.g. the discrete logarithm or integer factorization). If mathematics solves this problems then 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 ...

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

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

Recall that in Paillier encryption with public key $n$ of private factorization and $g=1+n$, encryption of plaintext $m$ reduces to: choose random $r$, $0<r<n$ compute and output ciphertext $c=(1+n\cdot m)\cdot r^n\bmod n^2$. Some ideas: In some contexts, it is feasible to pre-compute $r^n\bmod n^2$ in masked time, before the encryption itself, ...

3

Formally, what you're really looking for is a key derivation function (KDF). The Crypto++ API includes a PasswordBasedKeyDerivationFunction class, but that doesn't really seem optimal for your purposes; since you already have a high-entropy random seed, what you really want is a simple key-based KDF, not a fancy key-stretching KDF meant for use with ...

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

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 ...

2

The variables a, b, c, d, e, f, g, h are assigned on each round of the compression function main loop, but the interim hash values are considered only per message chunk (i.e. after all rounds have completed) I found the Wikipedia pseudo-code easier to understand than the description in your question, and it is clear there how the variables relate to interim ...

2

The following potential reasons occur to me why someone might not choose to use the CRT optimization: The implementor worries about induced faults (but not quite enough to implement the obvious protection against it). That is, with the CRT optimization, we process the RSA block both mod p and mod q separately, and then combine them. That means that if ...

2

Seems to be opinion-based, since there´s a lack of special point (which modification do you want to make?). But similar questions, that asked for specific modifications, get the same answer: in general, by modifying something without knowing specifically what you´re doing, you´ll be making it worst. Crypto algorithms are designed with specific things in ...

2

If $(R_1,c_1)=(g^{r_1}, A^{r_1}m_1)$ and $(R_2,c_2)=(g^{r_2},A^{r_2}m_2)$ are ciphertexts (with respect to the same public key $A$) corresponding to two messages $m_1$ and $m_2$, then $$(R_1R_2,c_1c_2)=(g^{r_1+r_2},A^{r_1+r_2}m_1m_2)$$ is an encryption of the message $m_1m_2$ (note that the calculations are performed in $\mathbb Z/p\mathbb Z$, that is, ...

2

First lets acknowledge this is a horrible hack - you really should find a way to do what you want more directly or risk code maintenance issues and likely bugs in the future. Second, while the question isn't about your key strengthening step it seems like you should ask about the security. There are lots of good key derivation methods out there and I don't ...

2

You are right about the interpretation of the power 10: it's a tenfold iteration. So we apply the function 10 times, starting with $x$, feeding the output as input for the next step. So C-like (I write x for the vector of 16 words $x_0,\ldots,x_{15}$): y=x; for (i=0; i< 10; i++){ y = doubleround(y) }; return y The inverse of little-endian is ...

2

Yours is a perfectly legitimate question. I know that C#, F#, Java and Scala have an in-built support to handle arbitrarily large numbers, i.e. as large as your computer’s memory.

2

Salsa/ChaCha and the other eSTREAM winners are likely to be the "fastest but still secure" options today. Don't forget authentication of course. Reduced-round ChaCha/Poly1305 is likely to be the fastest software-only option, due to tuned implementations in the libsodium and NaCl libraries. UPDATED: The following slide deck has good info on state of the art ...

2

... are secure for up to 30 years. Unfortunately, you didn't reference where this number comes from. Breaking asymmetric cryptosystems comes with various flavors: Scientific advances and new records, e.g. the factorization of RSA-768 in 2009 What intelligence agencies are capable of (it can be assumed to be a few years ahead of scientific advances, ...

1

I've implemented AES-128 with byte calculations for a small embedded systems, with optional on-the-fly key schedule calculation. See aes-min on github. The key schedule starting point for decryption must be obtained by calculating all the rounds of the key schedule. For a particular key, that decryption key schedule starting point only needs to be done once ...

1

Despite what I'm writing in the next three paragraphs, you should stick to the advice given by owlstead's answer and never make any even small change to a crypto algorithm (like changing the order of steps), even if you are a competent cryptographer (if you are, you probably wouldn't consider modifications except for very good reasons worth a publication). ...

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