Hot answers tagged implementation
8
This is not a limitation of the cryptographic functions, like SHA or PBKDF, since the zero byte isn't processed any differently.
Since the purpose of a salt is generally to travel alongside a human password, libraries that handle the password as a zero-terminated string might also handle the salt as such a string. Obviously, a 0x00 in the salt would ...
7
Yes, that omission weakens the cipher: the output $\mathtt K$ has a short cycle (at most 65280 bytes) for a sizable class of keys (one in 65536).
Not initializing $\mathtt i$ makes no difference in the values of $\mathtt i$ effectively used for the rest of the algorithm, since $0\equiv 256 \pmod{256}$; and hence has no security implication whatsoever.
But ...
7
For your application: "I need the (underpowered 8-bit) slave to be able to tell if a command issued is really trustable", RSA signature with low public exponent ($e=3$), or Rabin (an analog with $e=2$), is likely the most appropriate, assuming you can't trust the slaves to keep a key secret, which is the only realistic assumption unless that slave uses ...
6
The reason we, at the end of the compression function, add the input to the compression function, well, that's because otherwise the compression function would be invertible, and that would be bad.
Without that final step, the compression function would be invertible in this sense: given a desired compression function output and a message block, we would be ...
6
Using a static IV isn't simply "poor form" — it introduces crippling weaknesses to the security of your ciphertexts. Likewise, using correctly-generated IVs (the requirements differ from mode-to-mode, but cryptographically random IVs almost always meet those requirements) isn't "better"; it's absolutely necessary.
That said, there is absolutely no ...
6
Notice that the result says 67 mod 257.
All calculations here are being done modulo 257. So, 101^-1 is actually the modular inverse of 101 mod 257, which is 28. Similarly, 85 * 28 is also done modulo 257.
5
I believe what you are seeing is that .NET automatically uses PKCS #7 padding. This will always add padding. Thus if your plaintext is a complete block length, one extra block of padding will be added.
The reason the ciphertext ends up being the same in both of your test cases is that it is adding the same padding in both cases (see PaddingMode Enumeration ...
5
As fgrieu notes, the problem as specified is unsolvable: if the server alone should not be able to decrypt the files, then there must be something (in this case, the password) possessed by the user but not the server which is needed to decrypt them. If the user loses this extra information, there's no way the server can provide them access to the files ...
5
The fragment " what to do about padding the key ? " of the question looks scarily like transforming a password into a cryptographic key using some padding mechanism.
Doing this would be a known, serious, often made and often exploited mistake. A standard security assumption for ciphers is that the key is chosen at random, and a padded password is not random ...
5
That's because you can do ECDH by exchanging only the X coordinates of your public value; as long as the shared secret depends only on the x coordinate, everything works out.
Here's the fundamental property of elliptic curves that makes this work, the x coordinate of $nP$ is only a function of the x coordinate of $P$ (and $n$); it does not depend on the y ...
5
Yes there are.
The first publicly accessible McEliece implementation was this one from The Error Correcting Codes (ECC) Page, but it isn't particularly useful for reading, being quite obfuscated.
There's INRIA's SECRET group implementation called HyMES that implements something quite similar.
FlexiProvider (java library) contains quite a good amount of ...
5
It's generally strongly recommended you use an existing library for your crypto, instead of trying to reimplement it. One big advantage of a widely used existing library is that it's been improved over time to deal with new threats. You may be aware of timing attacks as a current weakness, but these libraries have already solved those problems and many ...
4
Hmmm, I think I might see the problem. In Generate_Subkey(), you have:
L <<= 1;
k.first = L;
if (k.first[128])
k.first ^= 0x87;
L <<= 1;
k.second = L;
if (k.first[127])
k.second ^= 0x87;
This sets K2 to either L << 2 or (L << 2) XOR const_Rb.
On the other hand, the pseudocode has
+ Step 2. if MSB(L) is equal to 0 ...
4
One way to see it is the following: RAM is slow. Modern processors can do several operations in a single clock cycles. However, a RAM access, such as retrieving data from an array based on a computed index, has inherent latencies and concurrencies issues; in the best of cases, you can do one memory access per cycle, and the result is not available for ...
4
Reflex answer: EAX. EAX does encryption and authentication, with minimal space overhead. EAX also has light requirements on the IV: it just needs a non-repeating value, so a simple counter can work. Possibly you already have a suitable counter or time stamp in your packets, that can be used as IV.
About replay attacks: you already expect that some packets ...
4
Does matching all the test vectors mean my implementations are valid mathematically?
Basically the comments got it, but test vectors are designed to attempt to hit lots of cases, but with high probability will not catch every single mistake. Should you do it? Definitely. Does it mean everything is perfect? No.
Is implementing mathematics correctly ...
3
Short answer: the problem you're trying to solve can't be fully satisfactorily solved.
With the assumption that an adversary control your system to the point of being able to read the RAM containing secret keys, you won't be able to define a secure system. The closest thing to a real practical solution is to bring in a trusted execution environment. HSMs ...
3
The OP wants a Key Derivation Function suitable for producing a key for the block cipher TEA, from Password and Salt. He is considering the use of PBKDF2, a common method designed for that purpose, which has a parameter controlling how slow the computation is, and thus the difficulty of password cracking.
PBKDF2 is a giant progress compared to practices ...
3
List questions are really off topic here, but since the question hasn't been closed yet:
Dan Boneh's Free Online Course
Introduction to Mathematical Cryptography
This website when you have questions (see the FAQ before posting)
3
While I haven't read the paper, I believe I can answer these questions:
I'm not sure if the implied modulus of each operation is $q$, as I added myself to the above formulas. Could someone please clarify this? The paper omits it...
No, the arithmetic is done modulo $p$. Remember, you're working in a subgroup of size $q$ of $\mathbb{Z}^*_{p}$; ...
3
As far as I can tell from your description, the modulus is p. To multiply two group elements, you compute x*y (mod p); because the generator g you choose has period q it'll all work out fine.
No, p, q, and g can (and must) all be public. This is ElGamal, not RSA we're talking about - the security comes from the (presumed) hardness of taking discrete ...
3
This is all about the question of risk assessment. Are you willing to risk all devices together so that if one key is compromised, they all have to be returned? What is the cost of one return, 100 returns, or 100,000 returns? What is the expense of issuing a master key? Of issuing ten master keys? Of issuing a thousand?
Do you have an estimate for how ...
3
I think what would be faster is using the hardware AES-NI instructions if those are available to you (and as a bonus, you avoid side-channel attacks, and it's much easier to implement, especially if you have intrinsics available to you, that way you don't need to go implement it in assembly).
As for your question, OpenSSL uses four 32-bit integers as the ...
3
This self-answer is heavily based on comments by Paŭlo Ebermann.
When performing AES decryption with on-the-fly computation of AES Round Keys, there is no choice beyond running the key schedule forward to the last Round Key (the first used when deciphering). The structure of the key schedule creates enough non-linearity and diffusion at each of the 10 steps ...
3
Almost all other languages can call C code, so using C is a safe bet.
Serpent, Twofish, Threefish and scrypt all provide C implementations. (See the links.) Some even provide optimized code. Writing objC or C++ wrappers seems unnecessary since both can call C funtions.
The sleep(3) library function is part of POSIX. So you'll find it on linux, mac, *BSD but ...
3
That sort of thing is known as multi-party computation, and you
should use a Socialist Millionaire Protocol for your particular instance.
3
The RELIC library has support for binary fields. Check the functions fb_inv_exgcd for inversion and fb_mul_lodah (which calls fb_muln_low and fb_rdcn_low) for multiplication. There is even a ATMega128 backend written in assembly, though it does not support 128-bit fields (but should give you a head start if you need to write it).
You will need to make a few ...
2
You have a few options. Some combination of the following will help.
Get a new job that will require you to use crypto. Could be hard w/o experience though.
Find a need for crypto at your current job, propose it to your boss and hope he/she likes it.
Find an open source project that uses crypto and find a way to contribute. This could make #1 easier in the ...
2
The answer to the question:
Is there any way to store private keys that are encrypted with a users clear text password and still have a way when resetting a password to preserve access to the users data
is actually yes. Simply store two copies of each private key - one encrypted with the user's password and one encrypted with the administrator's public ...
2
Cryptdb has a search component which implements techniques from this paper this might be helpful to get some insights and get started , cryptdb is open sourced code is available
Only top voted, non community-wiki answers of a minimum length are eligible
