2,476 reputation
524
bio website touset.org
location San Francisco, CA
age 30
visits member for 2 years
seen 3 hours ago

Cyclist. Rubyist.


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.
Sep
8
comment Breaking Double Encryption
To 1, I believe RC4 has enough output biases that it should be possible to detect its use with a small number of ciphertexts.
Sep
6
comment What is the most secure key expansion routine?
I don't care how a function tries to do it. There's no computable way to take a number with $n$ bits of entropy and deterministically produce a result with $n+k$ bits of entropy where $k>0$. If there was, we'd could trivially implement truly random number generators in software.
Sep
6
comment What is the most secure key expansion routine?
No key expansion (nor any computable function) can return a value with more entropy than what is input. The "best" you can accomplish (for some definition of the term) to is distribute the entropy evenly across the entire output.
Sep
6
comment What is the most secure key expansion routine?
A hash function is a function or method in a programmatic sense. It accepts an input, performs some bounded amount computation, and returns an output. What are the actual criteria you're looking for?
Sep
5
comment What is the most secure key expansion routine?
A hash function is a function. I don't think your expectations are very clear.
Sep
5
comment Base64 for a hash algorithm
I get the feeling that your question is poking at the surface of a deeper issue you're trying to understand. What's the context, and why is the nomenclature important here?
Sep
5
comment Using SHA-256 with different initial hash value
Why not simply use HMAC or NMAC, then, which have security proofs?