Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Encryption Security

Encryption Matters, Part Deux 40

Posted by Hemos from the taking-another-look dept.
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. "
This discussion has been archived. No new comments can be posted.

Encryption Matters, Part Deux More

Encryption Matters, Part Deux

Comments Filter:
  • 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...

  • 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!

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

    Sure, OpenBSD [openbsd.org]. (Super simplified history coming up.) Several years ago, they took the FreeBSD [freebsd.org] 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! [cthulhu.org]
  • what about the concerns in the orange book protocols about the integrity of data in memory. does the as/400 wipe clean the memory after it uses it or does it just free it, or is that os specific. also, is the data that flies around on the busses encrypted or no? that is, is the encrypted or the decrypted data in memory. does AS/400 allow for nonsecure (i.e. rlogin) connections? how fast is the hardware encryption, throughput, etc? and would it really be possible or reasonable to port linux to an IBM mainframe? If we could work out that kind of a solution for lower end/consumer use i would think that it would have hella applications...

  • Linux on AS/400? (Score:3)

    by phil reed ( 626 ) on Monday April 17, 2000 @07:58AM (#1127304) Homepage
    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 [ibm.com] for info.


    ...phil

  • 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 [inet-one.com], Ron Rivest's pages, and of course digicrime.com.

  • 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.
  • " 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. :-)

    --
  • Ummm.. linux already does run on IBM mainframes (read S/390). Check out the /. archives. The AS/400 isn't a mainframe, though some of the beefier boxes can get pretty fun.

    As for AS/400 Linux... I can't tell you, or I'd have to kill you ;-)

  • Ya, I tried that out a year or so ago... (Score:3)

    by cmat ( 152027 ) on Monday April 17, 2000 @08:48AM (#1127311)
    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!* ;)
  • Most of the time, they should, but when people troll, flame, or head off-topic at Score:1 or 2(+1 bonus), they should be hauled down. That's why I browse at 1, and sometimes 2. I would expect that the moderators do their job cleaning out the trash, so we don't all have to waste our time/bandwith on it. That's *far* more important than taking a post at '3' up to '5'... I can figure that out for myself.

  • this article annoys me (Score:4)

    by Signail11 ( 123143 ) on Monday April 17, 2000 @09:00AM (#1127313)
    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:different encryption methods (Score:3)

    by Signail11 ( 123143 ) on Monday April 17, 2000 @09:14AM (#1127314)
    "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:Sigh (Score:2)

    by dlc ( 41988 )
    • ...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! [cthulhu.org]

  • true, but... (Score:3)

    by kuro5hin ( 8501 ) on Monday April 17, 2000 @09:48AM (#1127316) Homepage
    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... (Score:3)

    by Signail11 ( 123143 ) on Monday April 17, 2000 @10:15AM (#1127317)
    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.
  • 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).

  • You can bring your own mouse and keyboard, but you'd also have to bring your own RAM and hard drive, which kinda sorta defeats the entire purpose.

    -----------------------

  • The meaning of kuro5hin is in the FAQ [kuro5hin.org]. And no, such a question would not get deleted. Only things like "STUFF LINUX UP YOUR ASS", which is childish and totally unnecessary. And when I refer to posts like that as spam, I mean spam in the sense listed in definition 2 in the Jargon file [tuxedo.org].

    And if both your parents are dead, my condolences. Losing a loved one sucks more than anything else.

    --

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

    --
  • >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).
  • The posts this person is referring to consisted of such sparkling gems as "STUFF LINUX IN YOUR ASS".

    Come on Rusty, you can't tell me you didn't laugh your ass off at that! I know I was cracking up just from reading it in your post!

    To be completely honest, you may want to amend your statement about what kind of posts you delete to include duplicates... just to be completely honest.

    Yet I wonder, since I agree that deleting trolls is usually the best decision, what will you do if k5 becomes huge and there are more trolls than you can handle? I suppose this is a more appropriate topic for posting on k5 itself, but it's not worth an entire article to itself, and this thread is already wayyyy offtopic.

    __________________________________________________ ___

  • Dupes: Yeah, I do that too. I think of that more as housecleaning though. But for completeness' sake, ok.

    It was kind of funny, the very first time. But SLIYA in four different articles, and submitted as a story for good measure was waaay too much. And as for scaling, I have a couple options. I may allow users to rate a comment "spam". X number of spam ratings and it goes to "potential spam purgatory" where admins can review and see if it really is. If it's not, it'll be reinstated, if it is, it just decays away. As usual, I prefer to distribute the work as much as possible. :-)

    --

  • 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 [snip.net].

    And, of course, the project page itself [snip.net].

    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 (Score:1)

    by Anonymous Coward
    Have there been any projects to build a completely secure OS?

    General rule of thumb, the simplier the system, the easier it is to make secure. I'm not aware of any "completely secure OS", but I don't hang around military types.

    The hardware-security-module (probably the most "secure" things in the consumer market) don't actually require a secure OS, if they are designed, manufactured, and updated carefully. One of the reasons they are secure, is because they just don't do that much. Security can benifit from simplicity.

    Offtopic: It is kind of funny to see the mindet change when a "software crypto" programmer starts to use a HSM. They want access to the raw crypto routines (because that was the way they did things before). Trouble is, raw access is generally not secure (OK, there are a number of ways around it, but I did say "generally").

  • 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.
  • is it da5id or da4id? (referring to your (kuro5hin's) FAQ page).

    --

  • It's "Da5id"
    ---
  • encryption is only to lock out the dumb or thoes that just don't care. if someone wants to find it out, they will. the best way to hide something is to make it look and act like something else. ie, make windows2000 look like it works.
  • 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 [kuro5hin.org] and 2 [kuro5hin.org] 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.
    ---
  • why take something simple, useful and reliable and port it into the most complicated hardware in the most complicated way possable that would be obsolete in a month do to a minor system upgrade.
  • Oh thank god. For a minute there I thought maybe I had misremembered my homage, and the whole thing was just silly. :-)

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

  • Having participated in the development of a "secure OS" for the only people that commission such things, I think I can safely say that it will never happen; nor is it necessary. Things like CMW are adequate for the everyday military use, and the tougher stuff would probably be more appropriately done using an "A1 router" and single-level networks. You don't get A1 for an OS -- you get it for a turnkey system. It's possible to abuse any useful system to create covert channels (cf. the recent posting on timing-based channels in Multics). So, you must code around those problems and establish procedures so that the box can't be abused in that way -- a very non-general-purpose box. To convince yourself that you have really covered things you can either stare at the code or believe the paper generated by the designers. For any kind of general-purpose machine this is infeasible. The OS we built had a 44BSD programmer API, but > 250,000 permissions in its database for a simple application. No way is a normal person (inside joke here) going to be able to come up with that and believe it is correct. So, you build simple, proprietary, reduced-function systems that you can reason about.
    A general-purpose "secure OS" is a pipe-dream (IMO, of course). Hardware is cheap -- why bother...
  • Thats very true.
    What you're talking about is called steganography, which is the art of hiding data in other data.
    Which is a very good way of hiding your information... But would seem out of place in top level security places. I mean, where am I going to hide my really really secret data... Well... I could hide it in my really secret data, then put it all in my not-so-really secret data...
    Unless you have some meaningless data that seems completely irrelevant to what you're hiding, then it becomes a bit pointless. And with top secret data, you're not likly to store it next to something pointless.. Like oh say some pictures of Natalie Portman... :o)


    Neurotic: Person who builds forts in the sky
    Psychotic: Person who lives in those forts
  • 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.

    Monitoring system load and process activity are administrative tasks. An operating system could restrict a user's ability to perform these tasks, e.g. not display load averages, only allow users to view stats on their own processes, etc.

    This type of data transfer is called a "covert channel," in other words, an unusual or unorthodox method of transferring data, where it's not obvious that data is being transferred at all. Steganography, for instance, creates a covert channel for data within images to which it is applied. This is distinguished from an "overt channel" where it is obvious that data is being transferred. Examples of this include FTP, sneaker net, telephone calls, etc.

    Guarding against allowing covert channels to be opened in a system isn't very easy. However, restricting administrative tasks to those with a "need to know" would nearly completely solve the problem, at least within the computer. Now the network is another story.....
    ---

  • Depends. If the computer contains an improperly modified MR FUSION PC Card, ISA version, simply accessing the BIOS setup may be enough to inadvertantly trigger WW III...
  • You might want to look into EROS (it's website is http://www.eros-os.org/). It's not out of the "hello world" stage the last time I checked, but I'm sure the guy could use your assistance.

Slashdot Top Deals

Parts that positively cannot be assembled in improper order will be.

Close