# 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

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

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

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

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

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

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

First of all to encrypt/decrypt data such institutions as banks use some block or stream ciphers for instance AES (Advanced Encryption Standard), which are very fast compared to RSA algorithm, hundreds times faster to process same amount of data. But block and stream ciphers use symmetric key (which is usually 128-256 bits random number, much smaller than ...

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

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

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

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

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

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

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

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

2

RFC 2313 specifies the RSAPrivateKey ASN1 structure as a SEQUENCE containing the INTEGERs $0$; $n$; $e$; $d$; $p$; $q$; $d\bmod(p-1)$; $d\bmod(q-1)$; $q^{-1}\bmod p$. The PEM format consists of such a structure encoded as Base64 and framed by the typical BEGIN/END RSA PRIVATE KEY header and footer lines. Thus, you can use any ASN1 library you like to ...

1

In a Ref10 based implementation, the conversion should look something like this: public static void EdwardsToMontgomeryX(out FieldElement montgomeryX, ref FieldElement edwardsY, ref FieldElement edwardsZ) { // montgomeryX = (edwardsZ + edwardsY) / (edwardsZ - edwardsY) FieldElement tempX, tempZ; FieldOperations.fe_add(out tempX, ref edwardsZ, ...

1

To simulate $n$ times iterated ECB encryption, you can set your input plaintext block as the IV, encrypt a "plaintext" consisting of $n$ all-zero blocks using either CBC or CFB mode (which are identical for all-zero plaintext), and take the $n$-th block of the resulting ciphertext (discarding the rest of the output). Note that, if your CBC mode ...

1

Public-key cryptography is not sufficiently computationally burdensome to where other approaches must be used for authentication protocols. Note though that what you describe is not actually public-key based. The verification of the MAC requires Dave and Bob to both have a shared key. Also, note that a random component must be included in some manner in all ...

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