2,233 reputation
423
bio website touset.org
location San Francisco, CA
age 30
visits member for 1 year, 10 months
seen 7 hours ago

Cyclist. Rubyist.


Jun
20
comment How big an RSA key is considered secure today?
While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes.
Jun
18
comment Length-preserving all-or-nothing transform
@fgrieu You're right. I'd originally conceived it as doing CBC a second time over the reversal of the ciphertext, but as D.W. explains in his answer, the entire construct is unnecessary in the first place. Oh well.
Jun
18
comment Using PBKDF2 twice with different argument order
Can it? By what property?
Jun
17
comment Does this protocol provide Perfect Forward Secrecy / are there potential security flaws?
Why should anyone bother to analyze this protocol? What advantage does the scheme have over TLS? What problem are you trying to solve, that is not already solved by existing protocols?
Jun
17
comment Using PBKDF2 twice with different argument order
At best, you're in a situation where you're using the algorithm in a way which hasn't been nearly as thoroughly cryptanalyzed. Better would be to use two separate cryptographically random salts, one for each usage purpose.
Jun
17
comment Length-preserving all-or-nothing transform
I'm sure there's something trivially wrong with that, but perhaps it will stoke some interesting discussion.
Jun
17
comment Length-preserving all-or-nothing transform
I'm thinking something like the following. Given some $i$-block message $m = m_{0} || m_{1} || \cdots || m_{i - 2} || m_{i - 1}$, let $c' = E_{CBC}(k, 0, m_{0} || m_{1} || \cdots || m_{i - 2} || m_{i - 1} || m_{i - 1} || m_{i - 2} || \cdots || m_{1} || m_{0})$. The ciphertext is $c = c'_{i} || c'_{i + 1} \cdots || c'_{i * 2 - 2} || c'_{i * 2 - 1}$.
Jun
12
comment Given $n$ bits, how many “truly random” sequences/numbers can be constructed?
Many well-designed PRNGs are capable of generating the full $2^n$ bits of their output space, even if they are not cryptographically secure. The important property of a CPRNG is that the next bit is always computationally indistinguishable, even if you have all of the previous generated bits.
Jun
11
comment Why must IV be sent with each packet?
To be clear, CBC does randomize subsequent blocks by XORing previous blocks within a message. A single message consists of one or more blocks, and each message needs its own unique (and random) IV.
Jun
11
comment Why does PBKDF2 xor the iterations of the hash function together?
Can you explain further what a "rho" structure is? It seems counterintuitive that this is a strong protection against a short cycle. If some $U_n, U_{n+1}, \cdots, U_{n+k-1}, U_{n+k}$ exist such that $U_{n+k+1}$ = $U_{n}$, it seems trivial that their XOR pattern will cycle through $2k$ unique values beginning at $U_{n}$.
Jun
11
comment Why does PBKDF2 xor the iterations of the hash function together?
Feeding the password back in doesn't negate the possibility of some $U_n$, $U_{n+1}$ existing such that $U_{n} = PRF(password, U_{n+1})$ (creating an extremely short cycle).
Jun
8
comment AES-128-CTR message integrity: Construction of HMAC
The HMAC only need be constructed over the whole message (e.g., $H(k, n || m)$).
Jun
5
comment One Time Pad for large changing files
I disagree that the information-theoretic property still holds. For example, one could determine through the pattern of flipped bits, whether or not the contents are likely to be (for instance) ASCII data (say if every 8th bit never changes).
Jun
4
comment AES/CBC fixed Initial vector use-case
To questions like this, I always have to ask: why? Why try to be clever? Why play with fire when it's so patently unnecessary? To save 16 bytes per request? Surely there are dozens of vastly more important things you can be spending your development energies on. Use a (cryptographically) random IV every request, slap an HMAC authentication tag on it, and move on to problems actually worth solving.
Jun
2
comment How do I produce a stream of secure random numbers from AES-Counter mode?
Since I'm feeling generous, I'll throw two more leading questions out there. What is the source of randomness for your cryptographic keys? How are you generating nonces, and how are you ensuring you're not using the same nonce twice?
Jun
2
comment How do I produce a stream of secure random numbers from AES-Counter mode?
An exhaustive list would be quite literally impossible. In the spirit of Bruce Schneier's anecdote, I'll give you one concrete attack outside of the scope of implementing AES-CTR correctly. Are you zeroing out the area of the disk that contained the unencrypted data, after you have encrypted it? In the case of an SSD, are you sure you're zeroing out that data (thanks to automated wear-leveling)?
May
31
comment How can one parallelize tasks in CTR-AES for maximum performance?
$\vert\vert$ is concatenation, $\oplus$ is XOR.
May
31
comment How do I produce a stream of secure random numbers from AES-Counter mode?
The examples given are merely some types of problems an implementation can have while still producing correct inputs and outputs. It is not an exhaustive list. That said, if you are storing this data on an offline host that you seem to believe will be difficult for any kind of attacker to get a foothold on, why exactly are you bothering to encrypt the data? What is your threat model, and what kinds of attackers are you attempting to thwart?
May
28
comment Uniform distribution/randomness of characters in the sha256 hash?
FYI, the letter/number pairs are just a base-16 representation of bytes (values 0-255). $\mathrm{00}_h = 0_d$, $\mathrm{10}_h = 16_d$, $\mathrm{f1}_h = 241_d$. There is no need to come up with your own (extremely odd) mapping between these bases.
May
28
comment How do I produce a stream of secure random numbers from AES-Counter mode?
As a rough example, what do you intend to do with these secret messages? Transmit them over a network? If so, an attacker on the wire can trivially flip bits in the plaintext, even if they don't know specifically what that plaintext is. The mantra often repeated here is: GPG for storage, TLS for transmission. They aren't perfect or infallible, but they get details right (well past simple application of AES) that you (or I) overwhelmingly likely wouldn't.