network profile
| bio | website | linkedin.com/in/nbougalis |
|---|---|---|
| location | Las Vegas, NV | |
| age | 35 | |
| visits | member for | 5 months |
| seen | May 1 at 21:59 | |
| stats | profile views | 3 |
I am a geek. I grew up playing with test tubes and beakers, reading history and philosophy books, making model rockets, drawing just about everywhere, playing basketball, and tinkering with remote control cars and planes.
I have worked as a software engineer for over a decade and although C++ is my favorite plaything, I have many toys at my disposal which I use to do amazing things. I have developed just about everything - from server software that manages tens of thousands of users to kernel drivers and from caching software to accelerate hard drives using SSDs to shiny user interfaces.
My interests are diverse, but right now, they include storage and I/O acceleration, encryption and security, software protection, cryptography, optimization, digital currency systems and next-generation interactive software and input methods.
For an up-to-date résumé check out my LinkedIn profile. You can reach me by e-mail at nikb@bougalis.net.
|
Apr 10 |
awarded | Autobiographer |
|
Mar 25 |
comment |
Where can I begin to study the math behind modern cryptography? I don't know that your book recommendation is as good as you make it out to be. Personally, I think that "Applied Cryptography: Protocols, Algorithms, and Source Code in C" by Bruce Schneier and "Cryptography Engineering: Design Principles and Practical Applications" by Ferguson, Schneier and Kohno are both superior books in every sense of the word. |
|
Mar 25 |
comment |
Where can I begin to study the math behind modern cryptography? While it's certainly true that the larger Universities will have courses in cryptography, they may not be good courses. The fact is that few Universities have really good cryptography courses that will provide a solid foundation. Most don't have any at all, and they just skim over the subject. At my University, I personally found that the courses offered by the Mathematics department (particularly, courses in discrete math, Galois theory, etc) were much more in-depth and useful in theory and practice than the course offered by the Computer Science Department. |
|
Mar 22 |
comment |
What is the difference between a hash and a permutation? Right - I agree with both your points: it's not a hash function in the cryptographic sense, and cryptographic hash functions aren't just be mere permutations of the input. |
|
Mar 22 |
awarded | Commentator |
|
Mar 22 |
comment |
What is the difference between a hash and a permutation? Your analysis is certainly extensive and detailed, but I must object to the statement that a "hash cannot be a permutation". Generally speaking you are correct, but given appropriate constraints a hash can be a permutation. Consider, for example, a hash function H(x) that one-to-one maps from every possible 16-bit integer to some other 16-bit integer by reversing the bits of the input (or, alternatively, XORs the incoming integer with the 16-bit value 0x029A). |
|
Mar 22 |
comment |
What is the difference between a hash and a permutation? @rath - Thanks, but that's alright. I think that my comment nicely supplements Oleksi's existing answer and works better in this context than as a standalone answer. |
|
Mar 22 |
comment |
What is the difference between a hash and a permutation? Right, a permutation will permute it's input and give you back something that is exactly the same length and has exactly the same elements as the input - just jumbled up. A hash function is a compression function - it takes something of arbitrary length and squeezes it down (or stretches it up) to a fixed length. Nothing stops you from treating a permutation as a hash function if you want to map fixed sized inputs to the same size output, but a permutation and a hash are different things. |
|
Mar 20 |
comment |
Google is using RC4, but isn't RC4 considered unsafe? @WatsonLadd I think it's somewhat unfair to attack an answer that, at this point, is 2 years old and make it appear as if it was "completely and utterly wrong" to begin with - especially when it isn't! Yes, new evidence has come to light about the security of RC4 when used with TLS/SSL and a comment noting that (very important) fact should be made. Yes, the answer could, possibly, be updated to account for the new information. |
|
Dec 21 |
revised |
Why is it important that phi(n) is kept a secret, in RSA? Mention that P and Q must be kept secret. |
|
Dec 21 |
comment |
Why is it important that phi(n) is kept a secret, in RSA? That's a fair point; I could have added a note about that, but the fact is that $P$ and $Q$ should be kept secret is well known and the original question was: "Why is it important that $ϕ(n)$ is kept a secret, in RSA?" |
|
Dec 20 |
awarded | Teacher |
|
Dec 20 |
awarded | Editor |
|
Dec 20 |
revised |
Why is it important that phi(n) is kept a secret, in RSA? deleted 8 characters in body |
|
Dec 20 |
comment |
Why is it important that phi(n) is kept a secret, in RSA? Beat me to it... perfect explanation. |
|
Dec 20 |
answered | Why is it important that phi(n) is kept a secret, in RSA? |
|
Dec 20 |
comment |
Why is it important that phi(n) is kept a secret, in RSA? Shouldn't that be: $\phi(n) = (p-1) \cdot (q-1)$? |
|
Nov 29 |
awarded | Supporter |
|
Nov 29 |
comment |
Message authentication codes construction Let's assume that you 'pad' both kinds of blocks with a 0; apart from that, everything is the same. Now, assume that there exists a message block 0.x.M[x] for some x which happens to be bit-by-bit equal to 0.r. Now what? That single block renders the construction insecure. By ensuring that there is no such x, you eliminate that risk. |
|
Nov 29 |
comment |
Message authentication codes construction I didn't mean arbitrary in the sense of "let's put random values", I meant that they arbitrarily chose to use 0 for r and 1 for the other blocks, and they could have just as easily chosen 1 and 0 respectively. Clearly they want the block with the seed to never match any of the blocks of data. The reasoning for this is explained on the section titled "SECURITY" on the beginning of Page 4 of their paper at cs.ucdavis.edu/research/tech-reports/1995/CSE-95-18.pdf |
