2,520 reputation
524
bio website touset.org
location San Francisco, CA
age 30
visits member for 2 years, 1 month
seen 1 hour ago

Cyclist. Rubyist.


Oct
14
comment Is it true the longer the key length is the more secure the encryption?
To TL;DR the answers you've received so far: increasing key lengths is increasingly pointless, as this defends an otherwise-secure cipher against brute force attacks. But typical key lengths are currently such that brute force attacks are outside the realm of physical possibility. What's important is building ciphers that are more resistant to other kinds of attacks like differential cryptanalysis, timing attacks, etc. Key lengths are already essentially the strongest component of modern cryptography.
Oct
13
comment How to use the key from a Diffie Hellman exchange?
That only works in two scenarios: a one-time pad, and a stream cipher. In the first case, you have to have truly random numbers and not numbers that are pseudorandomly generated. In the other, you would use the key with a preexisting stream cipher (like AES in CTR mode, or Salsa20) to produce a keystream that is later XORed with the plaintext. Regardless, this is something you absolutely should not be doing yourself; it is too easy to get any one of dozens of details wrong, resulting in little to no security at all. Use a library like libsodium or BouncyCastle to do the work for you.
Oct
13
comment How to use the key from a Diffie Hellman exchange?
There are many different symmetric encryption algorithms; their selection, implementation, and use is an enormous topic and warrants another question (or many).
Oct
13
comment How to use the key from a Diffie Hellman exchange?
The answer to this question can range from "extremely simple" to "extremely complicated". The simplest answer is, once two parties share a secret key of sufficient length, they can use pretty much any symmetric-key encryption algorithm to exchange a single message. A lede to the more complicated answer is that if you want to exchange multiple messages, authenticate (one, both, or more) parties, or have other features, the key exchange must be part of a larger protocol such as TLS.
Oct
9
comment Block Cipher Modes
Multiple of those answers are correct.
Oct
6
comment Session based AES with random key and static salt
Why not just use Diffie Hellman?
Oct
6
comment Session based AES with random key and static salt
Also, it's unclear what you mean by generating random secrets via an RSA public key.
Oct
6
comment Is this chat protocol safe?
It would probably help if you studied existing protocols like the ones I mentioned above, to understand how they provide things like forward security and authentication of chat participants. You can't (in general) simply bolt security features on to a protocol — they have to be designed in from the outset. Design of a secure protocol can easily take longer than the actual implementation.
Oct
6
comment Is this chat protocol safe?
What is your threat model? How do you feel that your protocol improves upon from existing ones like OTR or TextSecure, and what are the tradeoffs?
Oct
5
comment If a cipher has key length shorter than plaintext, then it is not perfectly secure
Consider: what does it mean for a cipher to be perfectly secure in the first place?
Sep
30
comment Is One Time Pad something like this?
XOR is just modular bitwise addition. Modular addition over entire bytes (or words, or any length) is also perfectly acceptable as it is invertible, every unique key maps a plaintext to a unique ciphertext, and every possible ciphertext can be the encryption of any plaintext with a key in the same keyspace.
Sep
29
comment Is One Time Pad something like this?
Also, the operation to combine the keys is typically bitwise-XOR, but can also be addition modulo values greater than two (also other types of invertible functions, though I'm not sure the specific requirements).
Sep
29
comment Cipher built from GPU primitives
Or alternatively, what GPU primitives are currently used in these hashes and why?
Sep
28
comment Message encrypted with a LFSR based stream cipher
This is a side point, but the question itself is nonsense. An OTP by definition must use a truly random key — a key generated by an LFSR with an input seed (or any PRNG using a seed) is by definition not truly random.
Sep
12
comment Self-Convergent Hashing
I still don't think this question is intelligible. I can't make sense of what's actually being asked.
Sep
12
comment Can we use numbers as a pad in the Vernam cipher - why or why not?
The implementation of the algorithm is literally nothing more than the XOR of the bytes of the message and pad. The real problem will be finding a true random number generator; java.util.Random isn't suitable for this purpose, nor is java.security.SecureRandom.
Sep
12
comment Can we use numbers as a pad in the Vernam cipher - why or why not?
I would find another resource to learn about cryptography. There is so much wrong in that image it hurts; the one-time pad is fundamentally uncrackable given that 1) the message and pad are of equal length, and 2) the pad is truly random, and 3) the pad is never reused. That's it. The bit about shorthand, abbreviations, and removing unnecessary letters is absolute nonsense. It's also not an actual implementation of a one-time pad, as it leaves valuable information like punctuation, numbers, and spaces unencrypted. Complete garbage.
Sep
10
comment Which block cipher mode(s) is most appropriate in these applications?
You may want to re-review block cipher modes of operation.
Sep
10
comment Which block cipher mode(s) is most appropriate in these applications?
Tip: Only two of those modes can be encrypted and decrypted in parallel. One of those remaining two modes is typically unsuitable for use in general.
Sep
9
comment Isn't a simple Vernam cipher as secure as known symmetric key algorithms?
And, to be clear, a cipher based upon a keyed CSPRNG is not a Vernam cipher because the keystream is not truly random. This is the difference between a synchronous stream cipher and a one-time pad: one is computationally secure, the other has perfect secrecy.