Slashdot Mirror
Encryption Matters, Part Deux
dlc writes "I'm sure Rusty has already submitted this, but just in case he hasn't, part 2 of "Encryption Matters" is now available on Kuro5hin.org. Part 1 was featured on Slashdot last week, and, if the lack of trolling is any indication, was well-received. "
just a thought. I don't think it's very feasible now, but maybe in a few years...
This would be the most extreme port possible, since the AS/400 security model is directly implemented in hardware. 64-bit native addressing, and the addresses include the drive space. Fully object oriented, again supported in the hardware. Check this site for info.
...phil
...phil
"For a list of the ways which technology has failed to improve our quality of life, press 3."
though I'd like to see Diffie-Hellman Key Exchange mentioned, and some coverage of the Web Of Trust and other key-cert approaches.
The big thing it needs is pointers to other resources - things like pgp.com, counterpane.com and Bruce Schneier's Applied Cryptography book, the Cypherpunks Archive, Ron Rivest's pages, and of course digicrime.com.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
OpenBSD started with NetBSD, not FreeBSD. Agree that if you need top security, they are probably your best free choice.
Even posting a link to an article where they would have had the good majority of posts is just irresponsible for anyone against trolling.
Its a waste for moderaters to post down. They should only be posting upwards not down.
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
" Part 1 was featured on Slashdot last week, and, if the lack of trolling is any indication, was well-received. "
Guys that was just ASKING for trouble, now the highest moderated post (at the moment) is God v.20 or some such non sense and there are about 15 trolls on the page.
You're right, there should be more links to other stuff. I'll try to make Inoshiro update that. Thanks for the reminder. :-)
--
There is no K5 cabal.
I am not the real rusty.
It's actually not that hard, really.
;)
First, you need a computer that no one can hack into; I recommend a 386 without a network card.
Next, you need to secure the local console so the evil wiley hacker can't break into your computer room and hack from the inside out. Cutting the keyboard cable and taking the ball out of your mouse work nicely.
Then, what a truly secure machine needs, is a A+ secure OS. MSDOS works well. "But", you say, "MSDOS has just about the WORST level of security imaginable!!". Well, then I suggest you remove any possible places to store malicious code so the OS doesn't have to be all that secure. Remove the RAM, Floppym CDROM and Hard disk.
There! A truly secure machine, without, and I think people will agree, a single security hole in it.
;) Chris
*ps - for those of you that feel the need to point anything out, please place all comments in the round file in the corner, thanks!*
-- Humans, because the hardware IS the software.
Some grips:
"The solutions to the problems of shared secret exchange and weak encryption are actually quite simple."
In theory, the solutions are indeed simple, but securely implementation of the algorithms and the correct protocols to use are actually very intricate. For example, the article completely fails to mention man-in-the-middle interception and relay attacks on public key cryptosystems, nor does the article mention the importance of padding, the prevention of replay attacks on one-time nonces, and the dangers of chosen signature attacks. The article presents just enough detail that a reader might believe that the topic is covered throughly, but not enough implementation guidance that a naive reader would be able to use the information given in a reasonable secure manner.
"Additionally, the private key can be used to encrypt things. This allows anyone with the matching public key to verify the author's identity."
NO!!! The private key can be used to encrypt *only nonces that the owner of the private key can control* (message hashes and the like). This signed hash allows anyone with the corresponding public key to *verify that the hash was not modified in transit*; it says absolutely nothing about the author's identity, nor does it authenticate the contents of the message signed, beyond that the message was signed by a person possessing the corresponding private key and was not changed such that the contents hashed were modified.
"Given two cipher texts that have some form of key overlap, all a cryptanalyst has to do is "slide" them around until the number of coincidences suddenly jumps."
The method of Kasaki superpositions would not be used to solve two different messages encrypted with the same pad. Rather, one would XOR the two messages together at different offsets and compute what is known as the "text autocorrelation function" (Shannon roughness). Subsets of the XORed messages would be tested with the ACF until a certain subset more resembled English text. The I of C method does *not* apply in this case, because the assumption of multiple messages encrypted in the same polyalphabetic glyph set does not hold.
"It is known by many names; message digest, fingerprint, cryptographic checksum, contraction function, manipulation detection code (MDC), and message integrity check (MIC)."
These words are not neccesarily synonymns; it is a very sloppy use of these technical terms to use them interchangeably. A message digest refers to the output of a hash function on a specific message. A fingerprint usually refers to the output of a hash function on a specific asymetric key. A cryptographic checksum is not defined in any general usage; usually, it would mean the same as a message digest, but one would not be sure. A contraction function does not exist; compression functions do, but they are used within cryptographic hash functions in the Meyer-Damgard model of collision resistance. The terms "manipulation detection code (MDC), and message integrity check (MIC)" are not in common use, nor are their acronyms. The author may be referring to Message Authentification Codes (MACs), which are essentially keyed cryptographic hash functions.
"Also, a one-way hash function, when properly designed, will not give the same hash value for two different preimages"
The pigeonhole principle necesitates that there will be collisions once the preimage size exceeds the size of the hash value. Indeed, if the hash function is a "perfect" hash function, it will approxiamate a random function, not a random permutation on the inputs. One would expect to find a collision after 2^(hash length/2) tested preimages due to the birthday paradox.
"If your password is not something simple like an english word, it is probably secure."
NO!!! Unless your password has over 40 bits of entropy (about a random alphabetical 8 letter password, about 3 randomly selected
"By now you should have a good understanding of the fundamental concepts of encryption."
If you read just this article, you would have a flawed understanding of the "fundemental concepts of encryption," but you would believe that you *did* understand it. A little knowledge is sometimes a very dangerous thing. Any serious cryptographic implementor should definitely buy _Handbook of Applied Cryptography_ by Menezes, et. al., _Applied Cryptography_ by Schiener, and _Codebreakers_ by Kahn (for historical background).
If you knew nothing about encryption, and read this article, you'd at least have an idea what people meant when they said "One time pad" or "public key". I should hope that no one is going to read this and go out and try to implement an algorithm! Being able to do that would take *way* more learning than we can possibly hope to offer.
--
There is no K5 cabal.
I am not the real rusty.
And if both your parents are dead, my condolences. Losing a loved one sucks more than anything else.
--
There is no K5 cabal.
I am not the real rusty.
Nope, I don't deny it at all. The posts this person is referring to consisted of such sparkling gems as "STUFF LINUX IN YOUR ASS". We don't care about that. This is the only sort of thing I do delete though-- the blatant and pointless spam. I'll leave it, even if it's a moderately good troll. :-) If you want a site that never deletes anything, and has no concern about it's S/N, I recommend slashdot. I simply have a different attitude toward people using my site to spew garbage like the previous poster does.
--
There is no K5 cabal.
I am not the real rusty.
>Since both of my parents have passed away, I find this truly offensiveSecondly, since your sign-in privacy statement stated that no part of the information I gave during signup would ever be made public, I have a strong case to bring a lawsuit against you now.ATTN: KURO5HIN.ORG DELETES POSTS
And? It's 'his' site (OK, I don't know the sex of the site owner).
Actually, it's in the FAQ of Kuro5hin's site... The answer is effectively "yes". If it's in a FAQ, it isn't a state secret, actually the opposite. The posting rules are on the same page too.
Sorry if my original post looks confused, I had a great one but somehow it got butchered between my browser and slashdot's server.
I didn't like the mean-spiritedness of the original poster myself, and I personally thought that the person had a lot of nerve getting offended at a reply to a troll post as if the original troll post is hunky-dory. No one knew about the parental situation as it is until it was stated, so really it couldn't have been meant to be offensive, therefore it usually isn't worth the time being offended about it. No one really knows if that situation is even true, given the anonymity of AC's on Slashdot, it's easy to just say it even if it weren't true to fish an apology out of another poster.
--
The shareholder is always right.
It's "Da5id"
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Since you obviously have an understanding of the matter, I'd love to see some "advanced cryptography" feature articles posted to K5, thanks to you.
Your "critisms" remind me a lot of the same "critisms" that "Beginning Security" parts 1 and 2 brought. They didn't mention a single thing about auditing code, probing firewalls, setting up security policies, etc. If you look at the feature box on K5, you'll see those went under different headings ("Security the Border," "Bullet Proof Code," etc).
What I'm doing is trying to help some of the newbies to become more clueful, and help others avoid problems. Once they've mastered the material, or at least have a basic understanding of the problem, they can move on to the more advanced stuff.
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Oh thank god. For a minute there I thought maybe I had misremembered my homage, and the whole thing was just silly. :-)
--
There is no K5 cabal.
I am not the real rusty.