Slashdot Mirror

"At six in the morning on Sunday, 8 June 1958, an early bird on the watch for worms in the Senate House lawn would have seen a strange sight. On the steep slates of the Seely Library there sat, huddled together with a faraway look in their eyes, three admiring policemen, a professional photographer in morning dress, two plimsolled undergraduates who looked as if they had not slept that night, and a shivering girl. Opposite them, on the leaded apex of the 85 ft high Senate House was parked an elderly black Austin Seven van, battered but outwardly complete. The roof party had climbed up convenient scaffolding to get a better view of this phenomenon. I cannot vouch for the policemens' thoughts - it was too late to prove any suspicions they may have had - but for one of the undergraduates this was the moment of victory, the climax to a year of dreams"

For all you jingoistic Americans fearing an insult to your national hacking pride, rest assured by visiting At http://hacks.mit.edu/

In June 1958, four engineering students at Cambridge University put an Austin Seven van on the roof of the Senate House overnight. There's a writeup of the methods used and the story of that night, complete with diagram, written by one of the conspirators. It's a document worth reading for anyone planning to follow in their hallowed footsteps.

M

For all you jingoistic Americans fearing an insult to your national hacking pride, rest assured by visiting At http://hacks.mit.edu/

In June 1958, four engineering students at Cambridge University put an Austin Seven van on the roof of the Senate House overnight. There's a writeup of the methods used and the story of that night, complete with diagram, written by one of the conspirators. It's a document worth reading for anyone planning to follow in their hallowed footsteps.

M

Setup was easy, the only tweak needed was with X11 and it was well documented here. The Yamaha sound card was not supported when I installed, but it is now.
There is an excellent site with information on all sorts of laptop setups here and a HOW-TO at LDP.

A random stranger? No. Someone whose past work I've seen and liked; quite possibly. I am planning to live in a house designed by someone without a degree in architecture (and quite likely no degree at all). Does that count? The house is about 350 years old.

I don't know how long architecture degrees have existed, but the Architecture department at Cambridge was only established in 1912, so the designer of the house I live in at the moment (at least the Georgian and Victorian bits of it) probably didn't have an architecture degree either.

Incidentally, the Cambridge Architecture department has a fairly cool paper on using Quake for architectural design.
--

A random stranger? No. Someone whose past work I've seen and liked; quite possibly. I am planning to live in a house designed by someone without a degree in architecture (and quite likely no degree at all). Does that count? The house is about 350 years old.

I don't know how long architecture degrees have existed, but the Architecture department at Cambridge was only established in 1912, so the designer of the house I live in at the moment (at least the Georgian and Victorian bits of it) probably didn't have an architecture degree either.

Incidentally, the Cambridge Architecture department has a fairly cool paper on using Quake for architectural design.
--

The silliness of Josephson's review is most evident in his discussion of cold fusion:

• Cold fusion -- the suggestion that hydrogen nuclei can be made to fuse together and thereby generate considerable energy at near room temperature, using an electrochemical process instead of the usual very high temperatures -- was a claim that seemed initially very unlikely to be true, though not totally ruled out. After some workers found themselves unable to reproduce the results initially claimed by Stanley Pons and Martin Fleischmann in 1989, a high degree of scepticism arose in the scientific community, especially after the publication of an official report declaring the absence of any evidence that fusion had taken place.

  It is interesting to look both at Park's account of the history of cold fusion and at that of the protagonists, presented in a video documentary Cold Fusion: fire from water (available from www.infinite-energy.com). Park impresses on the reader the fact that if the process that generates the heat is really fusion then one would expect to see fusion products. He fails to mention here, as the video does, that the small amount of such products anticipated, given the amount of energy generated, was eventually observed, and in just the right quantity. All mention of positive results, such as the experiment where, by what appears to be a sound method, it was found that the energy generated was considerably in excess of anything that could be explained conventionally, is collapsed into a paragraph where Park notes that many claims are soon withdrawn because of errors being found (as also happens in ordinary science).

  This device legitimises the dismissal of all positive results, and so also the corollary "cold fusion is no closer to being proven than it was the day when it was announced". This is a seriously misleading statement.

• "He fails to mention here, as the video does, that the small amount of such products anticipated, given the amount of energy generated, was eventually observed, and in just the right quantity." I've read Voodoo Science, but it appears that Josephson has not. All of this is discussed in excruciating detail in the book.
• "This device legitimises the dismissal of all positive results, and so also the corollary 'cold fusion is no closer to being proven than it was the day when it was announced'. This is a seriously misleading statement." Actually what's misleading is Josephson's description. It's been, what, 15 years since cold fusion was announced? I'm still waiting for the first demonstration of a working device.
• What Josephson fails to mention is the most damning evidence of all against cold fusion: if the device had really been producing the levels of energy Pons and Fleischman claimed, they would have been killed by neutrons. Subsequent experiments by Gai et al. showed no neutron emission in excess of (very low) background levels.

The Assayer - free-information book reviews

• call for observation
  
• 
  notes on tempel1 here and here
  
• 
  Interesting notes on deep impact
  
• 
  - Deep Impact FAQs
  
• 
  - paranoia link - suggests that the project's real, unpublished goal is to "miss" Tempel1 and intercept OX4, whose course with Earth in 2014, 2038, 2044 and 2046 is "possibly" an intercept.
  

-Marcel

-Marcel

YYYY-MM-DD is an ISO standard (ISO 8601). I found a summary of it here:

http://www.cl.cam.ac.uk/~mgk25/iso-time.html

One nice thing about it is that an "alphabetical" sort will order such values chronologically (in a directory listing for example).

I can't recall ever having seen YYYY-DD-MM.

Oooh, ooooh, Mr. Carter, Mr. Carter, that would be me. But right now I'm at work. Hmm, maybe I'll head down their after work and see how big it is...

I still think I prefer the statue of Lenin (direct from Russia), or the Troll under the bridge in Fremont though.

What I meant is that the usual reason for anonymity is political persecution. Strong encryption pretty much solves that problem, a lot easier than Freenet.

Bollocks[TM]

Strong encryption does nothing to protect you against traffic analysis, and in a totalitarian state traffic analysis alone is going to be enough to convict you. You send email to someone who sends email to some known dissident? Case closed.

Freenet does defend against traffic analysis at least to a degree (how effective this is I'm not really certain). So for people in totalitarian states, Freenet together with things like the steganographic file system offers plausibly deniable access to data and plausibly deniable storage of data. How successful this would be as an information-sharing system for dissidents is hard to say, but provided people are allowed real control over real computers (and the ability to load and configure their own software without supervision), and so long as those computers are connected to packet-switched networks over which it's possible to route encrypted (or steganographic) packets, it looks as if it would be unstoppable.

Of course, as soon as people start being arrested merely for owning a computer with software the authorities haven't authorised, or merely for sending a packet the authorities don't understand over a network, this all falls to pieces.

A research project called dasher allows you to type with only a moving cursor. It employs clever language models to make it efficient. An eyeball tracker on a PDA with this software may be easier and faster than fiddling around with a stylus. It is GPL'd, source and binaries are available.

Unfortunately watermarks can be removed.

No watermarking method is truly secure and useful unless

• It can be proved there is no feasible method of erasing or changing the watermark.
  
  
• The probability of the method incorrectly detecting a non-existent watermark is extremely low, ideally 0.
  
  
• The probability of the method correctly detecting a true watermark is very high, ideally certain.

Here's an example of how John Cramer's Transactional Interpretation eliminates weirdness:

"When we stand in the dark and look at a star a hundred light years away, not only have the retarded light waves from the star been traveling for a hundred years to reach our eyes, but the advanced waves generated by absorption processes within our eyes have reached a hundred years into the past, completing the transaction that permitted the star to shine in our direction."

Oh yeah, that's perfectly non-weird, alright!

Serpent is actually more secure than Rijndael, even if slightly slower. I personally use serpent in my loopback fs's, and it works really well!

Relating to open-source textbooks, there's a very good, anti-copyrighted text on applied mathematics here.

Estonia is also planning to issue smart cards as national ID cards starting from 2002. The project's website has very limited information in English, but the card will feature asymmetric cryptography (as it is designed to be main instrument to implement the digital signatures passed into law on March 8, 2000) and currently the project is in stage of tendering offers from smart card producers.

Since I was involved in the initial research, I have a couple of useful links:

• Kömmerling's & Kuhn's paper Design Principles for Tamper-Resistant Smartcard Processors is probably something everyone has to read before speaking up on the issue of physical security of these things.
• Schneier's & Shostack's paper Breaking Up Is Hard To Do: Modeling Security Threats for Smart Cards is a good read on the logical security issues.

if you could show me 5 sites that have valid, strict HTML of any version, or XHTML, I would be impressed.

• Debian
• anybrowser.org
• My homepage
• Cambridge University
• Microsoft (cough)

Smartcards should interest hackers. They come in two main variants: memory cards and processor cards. The first can be seen as a miniature, secure filesystem, the latter adds some kind of processing power to the former. Costs for CPU cards can be a few dollars each, even in large quantities.

There are some interesting properties of smartcards. First, they are assumed to be *somewhat* tamper proof. This includes a degree of difficulty in using physcial, electrical, even social engineering to find out what's inside. There are many nice papers on tampering, especially Tamper Resistance - a Cautionary Note
which is somewhat of a classic on the perils of believing something to be unhackable.

Ah, some nostalgia... the Java Card, which I had the fortunate to be part of developing back in 1997, is a cool device, deploying a Java VM in a few K of ROM and some 256 bytes of RAM. Yes, that is tiny!

Essentially, copying a smartcard like this is astronomically difficult, and at the very least, m uch more difficult than xeroxing a paper card or making a duplicate of a plastic card with a hologram.

Like any computer running software, there is potential for exploitation. Bugs in the smartcard's OS could allow complete access to the code it runs and what information is stored upon its EEPROM. Even without bugs, glitching the circuits can open the device up to exploits. And as for biometric data, a severed finger can get reach body temperature by spending a few seconds in the microwave.

For some ideas, check out Design Principles for Tamper-Resistant Smartcard Processors

I once got a mail from a friend who said he'd been in the Moller Centre and felt like he was in a Quake level. He claimed he'd run into some of the Churchill fellows[1] while in there, and had escaped alive, but with no ammo left.

[1] Note for Merkins: "fellow" is like a professor in the US, I think.

I once got a mail from a friend who said he'd been in the Moller Centre and felt like he was in a Quake level. He claimed he'd run into some of the Churchill fellows[1] while in there, and had escaped alive, but with no ammo left.

[1] Note for Merkins: "fellow" is like a professor in the US, I think.

Yeah... but... these files aren't encrypted. they're just watermarked. if they do it right, you will (barely) notice its presence when listening, but easily tell them apart (at the binary level). if you superimposed two songs, the watermarks would (might) interfere, possibly giving you an invalid watermark? Read this for pics or this for mp3.

I remember such an article. Perhaps the ever resourceful Markus Kahn can be of service.

http://www.cl.cam.ac.uk/Resear ch/ Security/tamper/

I remember such an article. Perhaps the ever resourceful Markus Kahn can be of service.

http://www.cl.cam.ac.uk/Resear ch/ Security/tamper/

WHoops.. messed up the link specification. Should have previewed :(

go HERE

-Laxitive

(a bit of history)

Way back in the day, Tim May (cypherpunks)
created a distributed communications prototype
called 'BlackNet', communicating through anonymous
remailers and doing file service, etc. It was
lacking in a viable anonymous payment mechanism,
but was a totally adequate proof of concept for
a totally secure filestore and info-market.

http://www.cl.cam.ac. uk/ users/rja14/eternity/eternity.html

Ross Anderson, a professor at Cambridge University
(and member of the SERPENT AES-candidate team),
worked on specifications for a system which
provided a "global filestore" capable of storing
popular or unpopular content in a distributed,
censorship-resistant fashion, based on electronic
payment, network communication, etc.

Adam Back then implemented "Eternity USENET",
using USENET as a backing store, with a special
web proxy to enter/retreive files.

Napster, Gnutella, Freenet seem to have come from
a completely different direction (particularly
Napster), rather than from the Eternity/BlackNet/etc. tree. Napster is
certainly the least general, but has had the
most commercial/userbase success, which may
be linked. It's certainly a lot easier to understand "Napster is sharing mp3s" than
"mojonation provides distributed file sharing
backed by electronic cash and a system of reputations and agents and brokers and ..." Time
will tell.

Publius is probably most directly inspired by
Anderson's Eternity Service, but I didn't check
citations.

Mojo Nation is from the same intellectual heritage
as BlackNet/Eternity/etc., but I believe the
foundations were laid at about the same time as
the others, with implementation waiting quite
a while for resources to be available. It looks
like the first viable opportunity to get
electronic cash widely deployed on the Internet...
I think that aspect of Mojo Nation (the mojo part)
is by far more important than the file-sharing
aspect, but it's a bootstrapping problem.

Titanium is as strong as steel, but 45% lighter. It is 60% heavier than aluminum, but twice as strong. Not surprisingly, it is often used in aircraft and missle hulls, as well as lacrosse sticks and mountian bike frames. It's used in that rainbow-hued metallic jewlery available at the mall. Because it's not corroded by salt water, it's used in desalination plants, propellers and other marine applications (including lures). Titanium is used to make "Shape memory alloys", notably nitinol (nickel-titanium). You can use nitinol wire to make walking robots, with the nitinol used as the musculature. It it used in pigments and is what makes white toothpaste white (TiO2). In fact, this is its major use. Plus, it's shiny. :)

________________________________________

Andrew

There must be something in the water at DAMTP[1]. People there do brilliant work, become famous, and then go stark raving bonkers. Now it's happened to Hawking, like it happened to Fred Hoyle and Herman Bondi before him.

[1] "DAMn The Physicists" as we used to say in DPMMS.

--

There must be something in the water at DAMTP[1]. People there do brilliant work, become famous, and then go stark raving bonkers. Now it's happened to Hawking, like it happened to Fred Hoyle and Herman Bondi before him.

[1] "DAMn The Physicists" as we used to say in DPMMS.

--

That HOWTO is good, but severely out of date. To quote Cha pte r 10 - Encrypting files and drives in Linux, BSD, and other Unices"

By: Kurt Seifried, seifried@securityportal.com, for http://www.securityportal.com/

Do you have files on your computer that you wouldn't want your spouse to read, or perhaps your main competitor. Chances are if you use your computer for work or general usage the answer is yes. Also what happens if you want to send a file to someone, or let them download it from you, but you only have access to a public site (like a free web hosting company). The answer is to encrypt the file, and fire it off. For UNIX you have several choices, PGP, and GnuPG, as well as Guardbot for web based file transfers. If you work with files that are sensitive (such as spreadsheets containing sensitive financial data) the constant hassle of encrypting and decrypting the file (as well as the fact a decrypted copy will be stored on the filesystem, leaving a window of opportunity for an attacker) can get tedious. If this is the case you will want to use software such as, BestCrypt (commercially licensed but free for Linux with source code), or PPDD (Private and Top Secret, GPL licensed) which are both very similar in execution and general usage.

Pretty Good Privacy is available as a command line driven program for most UNIX platforms, and there are a variety of front end GUI programs for it. I would not recommend using PGP on a UNIX platform since a completely OpenSource, and compatible replacement is now available, in the form of GnuPG.

GnuPG is a GPL licensed (a.k.a. completely free in every respect), written in Germany (a very pro-crypto and pro-privacy country). Since it is available in full source code chances are it has been ported to your UNIX platform (and if not try compiling it, it might work). You can download GnuPG as a compressed tarball of source code, and there are links to a number of source and binary packages for various UNIX platforms. Once installed GnuPG behaves very similarly to PGP. The first thing you'll probably want to do is generate a new keypair, simply use the command "gpg --gen-key", it will create a ".gnupg" directory in which to store your keys, option files and so on and exit, you then run it again and it will lead you through the key creation process. Choosing the defaults during key generation is a pretty safe bet, although you may want to use a 2048 bit keysize (realistically if someone manages to crack 1024 bit keys, chances are they can get at your 2048 bit key, however if they are only trying to brute force it a longer key is a good way to reduce the chances of that). For personal keys the expiry is typically set to "0" (that is to say they do not expire), however if these keys are for corporate use, or for really sensitive information it is a good idea to expire keys and rotate them (every month, year, decade, whatever your security policy dictates). The most important thing when generating a key (in my opinion) is the passphrase. This is a string of characters which should consist of letters (upper and lower case) numbers and punctuation marks, the longer the better (I'd say the bare minimum is 10 characters). This controls access to the private key, which is used to sign items (and if compromised means an attacker could easily impersonate you), and to decrypt data (meaning an attacker could access all your data). Keep your private key secure! If an attacker gains access to this key they only have to brute force the passphrase, which is typically a lot weaker then a random 1024 bit (or longer) key. Worse yet they may steal your passphrase, with a keyboard sniffer or similar attack, resulting in a compromise of your key. If the attacker does not have access to your private key they will be forced to guess it, which takes a brutally long time (on average however, there is a chance they may guess the key correctly on their first try).

Signing files is useful if you want to distribute a file to someone, and be able to prove that you sent it, and it was not tampered with. Internally GnuPG takes a hash sum (such as MD5 or SHA1) of the file (basically it reduces the file to a shorter, unique string of data) which it then encrypts with your private key, generating a signature. This signature can then be decrypted with your public key, resulting in possession of the hash sum of the file, simply take the hash sum of the file in question, and if the they match, then obviously the file is what it claims to be. This signature file can be a binary file, or converted into text (for example signing email, or distributing file signatures via email). To sign a file with gpg simply use :

which will create a detached signature of the file.

To verify the signature use "gpg --verify file.sig file". If all is well you should see something like:

If someone has fiddled with the file or signature you will see something like:

Encrypting files is also relatively simple, a person uses your public key to run the data through a one way algorithm which results in a seemingly random mishmash of data, you can then use your private key to recover what the original data was, thus decrypting it. To encrypt a file to someone you first need their public key, you can download it from their homepage (if they have it online of course), or you can go to a public key server, of which there are many:

http://pgp.ai.mit.edu/ - PGP key server
http://www.keyserver.net/ - OpenPGP key server

Once you have their key it is simply a matter of signing and encrypting the file (just encrypting the file is rare as there is no proof of who the data is from, unless you use some other method, like physically handing them a floppy disk with the encrypted file). The following is an example of me signing a file and encrypting it with my public key:

The user ID can either be the key ID (such as: 47D0D9A8), the email address associated with the key (seifried@securityportal.com)or the name (not recommended as these are not unique, there are many John Smith's). You will end up with a "file.gpg" that is binary, if you wish to send the file via email it is advisable to use the "-a" ("--armor") option which will result in "file.asc" and is ASCII text, so you can read it straight into an email, or print it out, mail it, and let them OCR and decrypt it at their end. To decrypt a file sent to you simply:

and it will display the file (hopefully a text file) to your screen, followed by the veracity of the signature (if you have the persons public key):

if you want to save the decrypted file simply use "--output filename" and it will dump the content to "filename". You can also use shell commands such as "|" or ">" to further mangle the output (this is useful if you have automated systems such as a reporting mechanism which sends encrypted emails to a central repository).

BestCrypt

BestCrypt is a disk encryption program available for Windows and Linux. The nice thing is you can create an encrypted container (a file that is then mounted as a filesystem), and use it in Windows or in Linux (as long as it resides on a partition accessible to both, so putting it on your Windows partition is fine since Linux reads almost all Windows partition types). BestCrypt consists of some kernel modules (so your kernel will need to support loadable kernel modules obviously, and it helps if you are using tools like depmod, modprobe and the kernel module loader), and a userspace utility called "bctool". This program is however officially in "beta testing" for Linux, and probably should not be used for critical data (if it is, make sure you have backups). After testing BestCrypt for Linux I am satisfied that even though the software is officially beta, it is probably stable enough for most users, however your mileage may vary, all sales final, and don't blame me for any lost data. The only real problem with BestCrypt is a severe lack of documentation, while there is a man page that explains basic options, there is not a single example of how to create and mount a container (I suspect the release will have documentation, their Windows version documentation is quite good, a half meg helpfile). You need to download the software first, available as a source tarball, and source rpm (very easy to install on an RPM based system). Simply download either one, I would recommend the source rpm if you can.

followed by a lot of text while it unpacks, compiles and assembles the source RPM and binary RPM. You should then have a:

Simply install the binary RPM with a:

If you do not have an RPM based system, or the source RPM doesn't work for you, compiling the source code directly from it's tarball should be possible. Simply download the file, unpack it to an appropriate place (such as /usr/local/src) and issue the commands:

And you should be up and running. The first step is to create a container (a file that is encrypted and mounted as a partition):

You can of course use the "gost" or "des" algorithms, I would not recommend them as gost is less tested then the "twofish" and "blowfish" algorithms that BestCrypt supports, and single des is to easy to brute force. The next step is to format the container, you'll probably want to use msdos if sharing with Windows (i.e. a dualboot Linux and Windows machine), or if just Linux then ext2 is a good bet. You can also specify the size, if you make it so small this can be a problem, but because it is a file and not a true partition you can easily create a new, larger file, move all the data to it and use it instead of the older smaller one.

Once the file is formatted you should be able to mount it:

As you can see it is mounted as a part of the filesystem, just like a floppy disk would be for example. Remember to control access to the directory hosting the encrypted files carefully, no matter how good the encryption, if you have it set world readable you won't have gained any security. Also remember that as a user, root owns the / and can take ownership of any file or directory and see what's in it. Alternatively if an attacker gains root access they can log your keystrokes (or terminal traffic) and gain your password (and access to your files). As always your security is only as good as the weakest link.

PPDD is similar to BestCrypt, but instead of creating a file, encrypting that and mounting it, it actually uses a partition which is encrypted and mounted using the PPDD driver, because of this it can do a few additional things BestCrypt can't. If you only want to encrypt a few directories then I advise compiling PPDD as a kernel module, but if you want to encrypt the entire file system (including what you boot from) you will need to compile PPDD directly into the kernel (although as of 1.0 it's not to hard). Unless you have a GPL only policy I would recommend using BestCrypt if you are new to this (it is easier to install and use, and you can buy support). PPDD does have one enormous advantage over BestCrypt however, you can encrypt all of the system, including the boot drive and swap partition, making it ideal for situations such as laptops with sensitive data and minimizing the risk (to zero if need be) of accidentally leaving sensitive data in an unencrypted location (such as the swap file, /tmp, and so on) so if you need a higher security level I would recommend PPDD over BestCrypt (simply because you can encrypt everything). Another advantage of PPDD is that is uses two passwords instead of just one for each encrypted filesystem, so you can give one administrator one password, and another administrator the other password, meaning no single person can gain access to the data. Unfortunately as of the writing of this chapter PPDD is not available for kernel 2.2.13 or 2.2.14, so you will have to run the older 2.2.12 kernel (which is the stock kernel on many distributions in any case).

Download PPDD, and unpack it in a suitable location, such as /usr/local/src/, there are several files you should read, most notable the README file, and once done install I would recommend reading the PPDDHow.txt file. Installation is rather simply with:

This will first test the kernel source to make sure it's the right version and so on, then it will test the patches, then apply the patches proper, and then create the devices needed (similar to what BestCrypt does). At this point you need to recompile your kernel, first make sure you go into the configuration (via make config or make menuconfig or make xconfig), and enable the PPDD driver (in the Block devices section). Then save the config file and recompile the kernel as your normally would. Once that is done you will have to install the new kernel (copy it to /boot typically, edit lilo.conf and rerun lilo). Once you have rebooted you will want to build the tools for PPDD and install them with:

At this point you should be ready to use it, however I would recommend running the tests with:

They take a while to run, but it will save frustration later on if something is broken. Using PPDD is relatively simple, there are a number of utilities for creating, managing, encrypting file systems, and so on. You will also want to set the permissions and ownership on the /dev/xxxx that contains your encrypted data so that only root has access to it, PPDD will complain otherwise

At this point you should have a directory called /crypt which is /dev/hda3 (although on df and the like it will show up as /dev/ppddx). I will cover how to encrypt you entire filesystem with PPDD, at a later date however (it is extensively documented though).

Another new possibility is Guardbot, which password protects www pages. Essentially there are two components, an applet that encrypts the data, using DES (56 bit keyspace), and an applet that will decrypt the data with the password you provide. The advantage of this over traditional server based methods of control (such as htaccess in Apache) is that the user manages it fully, and can protect each file individually without much setup. To fully take advantage of the keyspace available your password must contain upper and lower case letters, numbers (and punctuation marks, but this can confuse users) of around 10 letters, however since people tend to choose less then random passwords a longer password then this is advisable. This program would be useful for getting files to other people cheaply (simply sign up for some free web space, post the file up, and get the password to the other person securely).

It is no longer enough in some countries to encrypt your data to prevent access to it. Recently in Britain a law was created making it a criminal offence to refuse to give up encryption keys or plain text versions of encrypted data.

StegHide hides data in files such as sound and picture files where not all of the bits in a byte are used. Since the data is encrypted it will appear random, and proving that the data is actually there is difficult. The only downside is to store a one megabyte file you need a sound/picture file of several megabytes, which can be cumbersome (but hard drives and high speed access are becoming cheap so it's a moot point). You can get StegHide at: http://www.stego.com/.

Steganographic File System actually hides data on your harddrive, making it difficult to prove that it even exists. This can be very useful as the attacker first has to find the data, let alone break the strong encryption used to protect it. You can get StegFS from: http://ban.joh.cam.ac.uk/~adm36/StegFS/& lt;/a> .

OutGuess hides data in image files, meaning you can send files in a way that won't attract to much attention (and can't really be prooved either). You can get it from: http://www.outguess.org/.

Connected has got some reasonably accessable articles.

There's 225 million American, 5.8 billion other people on this planet, most whom don't speak English and don't write in modified, vowel poor, aplhabets.

Can you say "ASCII is cutting us off from big potential markets?" Sure... I knew you could...

Unicode will spread because it's NEEDED.

Actually, sending ASCII is equivalent to sending text in the UTF-8 encoding of Unicode/ISO-10646, since characters 0x0..0xff are exactly the same in both encodings. UTF-8 is a widely accepted encoding of Unicode. Hence, using ASCII is transparently upward-compatible with Unicode, while using 8-bit encodings such as ISO-8859-x or Windows Code Page 125x is not.

So when we have software that's actually capable of displaying the full range of UTF-8-encoded text, complete with character composition and correct bidirectional algorithms, then ASCII will just work.

However, note that some folks don't like Unicode due to the Unified Han space. While Chinese, Japanese, and Korean writing systems all share a set of similar glyph shapes, the style of writing them differs among writing systems: there are styles that are recognizably Chinese, Japanese, or Korean. The actual glyph shapes, of course depend on the font that's being used. So, for example, if you have a document that contains text in both Chinese and Japanese, you have two choices:

1. Pick one. Use either a "Chinese" or "Japanese" Unicode font to display the entire document. You might as well raise your middle finger to readers from the place you didn't pick.

2. Use different fonts to display the Chinese section and the Japanese section. Suddenly you don't have plain text anymore, but a document that requires font metatext to travel with it. You might as well use the system of different encodings we have now, since that already works.

In my humble but terribly insightful opinion, the differences between Chinese, Japanese, and Korean styles of the Han character space are equivalent to the differences between similar-looking characters in the Latin, Greek, and Cyrillic alphabets, which do have separate characters for "Uppercase Latin letter A", "Uppercase Greek letter Alpha", and "Uppercase Cyrillic letter A" in the Unicode spec.

But then, what do i know?

Have you tried here? I personally found the Introduction to LaTeX2e to be very helpful.

That has already been done, and it's called serpent. You can find more information about it here.

StegFS allows you to have mandatory number of data layers. w/o knowing password there is no way to determine how many layers are there. They ask for password, you give them one. Or two. Or five. There is no way to determine if you had given them passwords to all layers of data.

... black holes also show up in superstring theory (well technically M-theory). You can use a D-brane to model the black hole, and this technique has been used to acheive a first principles calculation of the microscopic entropy of a black hole, whereas traditional techniques used fairly general arguments and a bit of hand-waving.

On a side note, string theory may suggest ways that information can escape from a black hole due to violations of locality. This is still very much open to debate though.

For more information, see here at the Cambridge University's Relativity pages.

Version 1.0 could include a cryptographic hash of a text message included in version 1.1, version 1.1 could inclue a hash of a message appearing in 1.2, and so on. This would let users know that that a newly posted version was indeed from the original authors, without identifying those authors.
Have a look at the Guy Fawkes Protocol

A paper and ink listing of known public keys, published via Cambridge University Computing Laboratory.

Modula II wasn't bad. I did a fair amount of embedded-system programming in Modula II, and it really was what you needed when you had to make a EPROM to run the program and had very limited debugging tools. Most of the time, if the program compiled, it ran properly. This is the real advantage of restrictive languages - a higher percentage of the bugs are caught at compile time.

Modula III, the first object-oriented member of the family, never really caught on outside of DEC's old Palo Alto research operations. A free compiler is available for both NT and Linux, but it's not really maintained. Compaq has stopped all work in that area.

Oberon is an OS and language, combined. I don't know enough about it to provide any greater detail.
You're not missing much. Oberon's idea of a user interface is, well, painful. Again, there are free Linux and NT versions, so you can download and try it.

One always wonders how it would have turned out if the Stanford CS department hadn't denied Wirth tenure.

In many ways, Pascal was a better language, but Pascal had some inane limitations that stemmed from Wirth's academic orientation. Even Knuth criticized such things as Wirth's flat refusal to allow a "default" on case statements. "This is mindless pedantism up with which I will not put", Knuth wrote. Pascal also originally came with a lame I/O system designed for the CDC 6600 (a '60s supercomputer), no separate compilation, and no compile-time arithmetic, so you couldn't write "var tab[0..lim-1]" when "lim" was a constant. Unfortunately, that painful version became an ISO standard, leading a generation of programmers to beat their heads against the walls of the language.

This left an opening for C, which came with a system programmer oriented I/O library and, in time, a whole OS with free source code. Still, for much of the 1970s and through the mid-80s, serious researchers used Pascal. The Apple Lisa and the MacOS, for example, were in a dialect of Pascal, as were most early Mac applications. (The Lisa even had an object-oriented variant of Pascal by 1983.)

What killed Pascal, I think, is that Berkeley UNIX came with a truly lame Pascal implementation. Its horribly inefficient subscript checking implementation (a subroutine call for every subscript check) and miserable generated code convinced a generation of programmers that Pascal sucked. Still, the microcomputer world got a lot of work done with Turbo Pascal in the 1980s. It wasn't until the rise of Microsoft (a C shop) and the fall of Borland (a Pascal shop) that Pascal was crushed. One could argue that the decline of Pascal reflects Microsoft's dominance.

Version 2 (which included support for subroutines, amongst other incredible inventions) was introduced on August 1949. It loaded the program, translated it from what could be described as a simple assembler. As 'Initial Orders 2' added the subroutine stuff; a library function that was used by the program while running, maybe it counts as the first OS. A few details about EDSAC are available here

In the meantime why not hedge your bets by following a coding or admin career, but offering history of computing classes at the local community college? I actually teach history of garden design in the evenings. You'd be surprised at how many people will sign up for a history class in an area in which they're vaguely interested.
Derwen

In the meantime why not hedge your bets by following a coding or admin career, but offering history of computing classes at the local community college? I actually teach history of garden design in the evenings. You'd be surprised at how many people will sign up for a history class in an area in which they're vaguely interested.
Derwen

The "Hands Off X!" which is mentioned apparently was a talk about how Scheifler had helper programs interface to X. I think the software is used in Xtalk and a2x

http://www.dpmms.cam.ac.u k/~werdna/XFree86-3D-status.html
nf

Of course, for a more radically "innovative" approach, Microsoft already hired Simon Peyton-Jones, of some "fame" in the world of Functional Programming, and furthermore, he already had C--, Still Another "BCPL stepchild."

There are probably a whole pile of "cool things" that have been deployed internally that might actually be good things that will never see the light of day because, as Matt Welsh observes,

What you end up with, after running an operating system concept through these many marketing coffee filters, is something not unlike plain hot water.

That can apply as well to languages as to OSes...