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. "

Comments

different encryption methods

[war2k1]

Have there been any projects to build a completely secure OS? It would be interesting (i think) to build an OS from the ground up that made the a1 security level look like windows nt... It would need a chip to handle the cypher though. Think about it. If you had what would amount to a chipset that would do the encryption/decryption. things would only be decrypted when sent on the last leg. For example, all information in memory and in the filesystems would stay encrypted until the chipset sent them out over an authorized chanel (i.e. to the processor, the pts or the tty). Of course it would take a huge amount of processing power, but it would mean the ultimate in security. Can anyone point me to a book on OS development or help me build this monster?

just a thought. I don't think it's very feasible now, but maybe in a few years...

Re:different encryption methods

[Dr Caleb]

IBM AS/400 series comes with built in hardware encryption.

The chipset is proprietary, and the data cannot be read by another AS/400. If you try to remove the drives etc from the unit, they will not function! Conversely, if you add more drives, you have to know the master key to get them to function...as well if you replace these chips, the unit will not function.

Might be worthwhile to port Linux to one of these boxes! Bonus points for the student!

Re:different encryption methods

[dlc]

• Have there been any projects to build a completely secure OS?

Sure, OpenBSD. (Super simplified history coming up.) Several years ago, they took the FreeBSD source tree and began combing it for insecurities and weaknesses. It now ships very tightly closed up by default, with most daemons off, SSL and SSH included as part of the core OS, etc. They haven't gone to the lengths you describe (I don't think), mainly because they need to maintain POSIX compliance and source-level compatibility with other Unixes and *BSD's. Definitely worth looking into if security is your passion.

darren

Cthulhu for President!

Re:different encryption methods

[Signail11]

"ground up that made the a1 security level look like windows nt..."

If I'm parsing this correctly, it seems as if it would be essentially impossible for any system with a GUI to realistically be certified A1. One must have a mathematical proof of correctness of the same attributes as B1, B2 systems in order to be certified A1; the mere fact that a mouse can be moved, with all that entails (cutting/pasting, etc.), means *massive* overhead to keep track of Mandatory Access Control (the standard secrecy++, permissiveness-- model would impose insane amounts of bookkeeping to make sure every operation was permissible). Perhaps with the capabilities scheme (ex. Eros OS) could be extended to offer A1 level security, with a reasonable amount of implementation assurance, but it still seems very difficult to get the IOP flow done efficiently and securely. It's an interesting project, and I would love to hear more about it if you ever get started.

Re:different encryption methods

[Syberghost]

This would be damned unlikely. Not impossible, but orders of magnitude harder than porting it to most architectures.

See this link: comments from IBM employees to the "Linux on AS/400" project.

And, of course, the project page itself.

Good luck. Personally, I think the effort would be better spent trying to write an application emulation layer, instead of porting the whole OS, but it's no skin off my nose since I won't be on either project. :-)

Re:different encryption methods

[FigWig]

Besides the basic MAC problems of a GUI (cannot copy and paste from a higher security file to a lower security one, etc.), to have a truly secure computer you really have to garauntee that there is no way to communicate between secure users and less secure users. Imagine I write a program that allocates a large amount of memory, but deallocates it and reallocates it in a pre-programmed way. By encoding information in a morse code type fashion into this activity pattern another user could monitor the system load and transcribe the info.

Of course they could just walk down the hall and talk to each other.

Linux on AS/400?

[phil reed]

Might be worthwhile to port Linux to one of these boxes! Bonus points for the student!

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

It's a Good basic introduction

[billstewart]

The article hits many of the basic topics,
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.

Other resources.

[kuro5hin]

You're right, there should be more links to other stuff. I'll try to make Inoshiro update that. Thanks for the reminder. :-)

--

Ya, I tried that out a year or so ago...

[cmat]

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!* ;)

Re:Ya, I tried that out a year or so ago...

[PD]

Actually, it's not so secure. I can bring my own mouse and keyboard, and where would you be then? To get more secure you'd need to entomb the machine in concrete. Then, I'd need a jackhammer before I could work on it. If you drop the thing into the ocean, I'd need a salvage ship and a robot submarine before I could work on it.

100% security makes computers too hard to use. A better solution would be to make it cost more to get the data than the data is worth. An example of what NOT to do is to put code-word (higher than top secret) information on a Laptop computer, and then leave the laptop in a conference in the state department. That's what was just reported in the newspaper.

The more sensitive data, the more security required. Something along the lines of the security our nuclear arsenal is what code-word classification should be given. That means, it never gets onto a laptop computer, and it can never be accessed unless the consent of, say, a dozen 4 star generals is given by a physical act (turning a key).

this article annoys me

[Signail11]

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).

Re:Sigh

[dlc]

• ...that was just ASKING for trouble...

Yeah, I was kind of hoping it would be edited a bit before it got posted...

The only solution is to moderate everything else in this discussion up. :)

darren

Cthulhu for President!

true, but...

[kuro5hin]

You're right about all your points. However, this was meant to be a very high-level intro to cryptographic concepts, for the beginner. You obviously know more than a beginner would, so you probably didn't learn anything here.

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.

--

Re:true, but...

[Signail11]

That's the problem; when it comes down to it, cryptography is a science of the details. There is a very important difference between, say strong primes and safe primes. The proper phrasing and selection of words is critical to conveying meaning in all fields, but especially so in one as specialized and detail-oriented as cryptgraphy. As a big picture introduction, your article is fine, although it would be nice if less detail were placed on the one time pad, however, I think that it should be prefaced with an advisory notice that one shouldn't try to implement a home grown security package once through reading it. I've seen too much crappy and insecure software that could have been bettered by a more through knowledge of basic cryptographic principles and the many intracacies and pitfalls that lie between a simple theoretical description and the actual secure implementation; posting links to the standard references (HAC is very useful, and available for reading online) would be a great improvement.

I would love to see you contribute.

[Inoshiro]

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.
---