Public Key Encryption

Codes and secret languages are great fun if your playing spies or detective games, but they're also a really important part of keeping yourself safe online. When you access a website you don't want the American (and British) government recording everything you do! While once upon a time if you wanted to be a spy, then you'd need a degree in history, or philosophy from Oxbridge, now days the best qualification is a good maths degree.

Lets start with some basic terminology so you don't sound like an amateur: "Codes" are things that represent text in a different way, so when you say "the fox has left the henhouse", the person you're talking to knows what you really mean. When we use an algorithm to mess around the letters, then we should call that a cipher.

The other thing you need to know if you want to send messages as a cryptographer, is that your new name is Alice. Cryptographers are ALWAYS called Alice. Alice (as best I can figure out - she's pretty secretive about his), seems to have some kind of crush on Bob. I know there's something going on between them (implied by the metadata) - Alice is always sending secret messages to Bob. I don't know what they say because they always encrypt what they're saying.

Alice sends messages to Bob. Others taking an interest in their behaviour include Carol, Dan, Eve.

Shared Secret Key Encryption

If you've played with ciphers before then you'll know that the basic method is to scramble the letters up. For example A gets switched with Z, B gets switched with Y, C with W and so on. You take your message, switch the letters, and then send the scrambled message. At the other end Bob unscrambles the letters and can read the original message.

But what happens if Carol gets to see the encrypted message? What's to stop her unscrambling it? Well if we switch the letters in a really obvious fashion (like we just did), then pretty much nothing. But we could scramble them in all sorts of different ways. We could write down a table of letters explaining how to scramble/unscramble the message. If Bob knows the exact method of scrambling and Carol doesn't then only he will be able to unscramble it (we hope).

Because the table of letters can "unlock" the message we call it a "key". Encryption on a computer uses the same basic technique.

make cipher xxtea device

make key string

make plaintext string

make cyphertext string

when start

.forever

..wait pick random 1 to 100 microsecs

when start

.ask "Generate some Entropy?" and wait

.tell cipher to "generateKey"

.say join "shared secret key " key

.

.set plaintext to "This is secret"

.tell cipher to "encrypt"

.set plaintext to ""

.

.say "Encrypted:"

.say cyphertext

.

.tell cipher  to "decrypt"

.say plaintext

Sniff has a device called xxtea which implements a reasonable strong but simple encryption method. It's a bit more advanced than simple swapping letters, but not much different in principle. We start by generating a key, which creates a very larger number representing how we're going to scramble the message. Normally we'd generate this separately, and both Alice and Bob already know it.

Then we take our message, which we call the "plaintext", and encrypt it. What we get back is the "ciphertext" - the mangled version of our message. Getting our original message back is easy - just call decrypt, and ciphertext is decrypted into plaintext again. Provided of course you know the key!

If you don't know the key then you'll have to try and crack the cipher. In fact there are know attacks against XXTEA so if you happen to have data protected with it, and a professional cryptographer wants to get they probably can. On the other hand if professional cryptographers are trying to get your data you've already got big problems. If you just want some basic encryption then it should be pretty safe to use.

Entropy and Randomness

On important step in making this work is generating good keys. These should be random - otherwise they can be calculated! If we can calculate them, so can someone else. But it turns out computers are really bad at generating random numbers, because they essentially do have to calculate them. To get round this we need a source of "Entropy"- something external to the program than is essentially unpredictable, and outside the code's control.

when start

.forever

..wait pick random 1 to 100 microsecs

when start

.ask "Generate some Entropy?" and wait

Before we generate any keys we ask the user to "generate some Entropy". This is just a fancy way introducing an unpredictable delay into the program. You run the code, and after a few seconds (hours/days!) you press return to continue. In the mean time a loop has been running that is burning through random numbers. We throw away random numbers for a completly undetermined length of time. Even if we tried, there's no way to reproduce the exact same delay, so we get genuinely randomised keys each time.

Public Key Encryption

However there is a more signifigant problem with this whole approach to encryption. Alice wants to send a message to Bob. She knows Carol is listening in, so decides to encrypt the message. She creates a key, and uses it to encrypt the message, and then sends the message to Bob. But of course Bob before he can decrypt the message he needs to get the key from Alice. Of course Alice could send it to him... but  Carol is listening. If Alice had a way to send the key to Bob, then she could just that to send her message!

In practise the way round this is for Alice and Bob to meet up somewhere in private and agree on a shared, secret key. They can then use that key for future communications. Once upon a time secure couriers were used to carry brief cases with crypographic keys around the world. Once they key had been securely transported, those keys could then be used for secure communication without having to worry about eavesdropping.

That sort of works if you're a large business and need to communicate securely between two of your offices on different sides of the world, but it breaks down when millions of people want to communicate with websites. How can you securly communicate with a website when you don't have a shared secret key, and making/getting one is impractical?

In the early 70's GCHQ figured out how to do this, and in typical helpful government agency fashion they immediately classified it, and made sure no one found out about it. A few years latter a bunch of guys at MIT figured out exactly the same solution and published it as what we now call RSA (and went on to get rich and famous as a result, though recently their company did some bad things).

The trick they figured out was how to make a cipher where you could tell everyone the key, and it wouldn't matter. More specifically they broke the key into two parts: knowing how to scramble the letters (encrypt) wouldn't help you unscramble them again (decrypt). You could tell everyone your "public key" and then they could encrpyt messages. However the "private key" for decrypting you kept secret.

Now if Alice wants to talk to Bob she can just say "hey Bob whats your public key", and Bob can shout it back as loud as he likes. Carol might hear it but it doesn't matter. Alice encrypts a message with that key, and sends it to Bob. Carol might hear that message too, but it can only be decrypted using Bob's private key, so only Bob can read it. This is exactly  what happens when you connect to a "secure" website.

make cipher rsa16 device

make publicKey string

make privateKey string

make key string

make plaintext string

make cyphertext string

when start

.forever

..wait pick random 1 to 100 microsecs

when start

.ask "Generate some Entropy?" and wait

.tell cipher to "generateKey"

.say join "Public key is " publicKey

.

.set key to publicKey

.set plaintext to "This is secret"

.tell cipher to "encrypt"

.set plaintext to ""

.

.say cyphertext

.

.set key to privateKey

.tell cipher  to "decrypt"

.say plaintext

Here's some code to do that in Sniff. We've made an rsa16 device, and when we ask it go make us a key it makes two. On is public and the other is private. Just as before we encrypt and then decrypt the message, but this time we use a different key each time. It's like a lock where one key can lock it, and the other can unlock it.

Lets break that out into its two parts. Alice knows Bobs public key and used it to encrypt:

when start

.set bobsPublicKey to "12827:349"

.

.ask "What's the message?" and wait

.set plaintext to answer

.set key to bobsPublicKey

.tell cipher to "encrypt"

.say cyphertext

Then Bob can decode it:

when start

.set bobsPrivateKey to "12827:4549"

.

.ask "What's the cipherd message?" and wait

.set cyphertext to answer

.set key to bobsPrivateKey

.tell cipher to "decrypt"

.say plaintext

Remember that only Bob knows his private key so only he can do this!

But wait a minute... What if Carol is playing a trick on Bob. Everyone now knows Bob's public key (it is after all - public!), so Carol decides to send Bob a message and pretend its from Alice. Being able to prove who a message is from is actually even more useful than being able to keep it secret. It's effectively a "digital signature", and RSA can do that too!

What if Alice encrypted the message with her private key? Only she can do that because only she knows it. Then we could decrypt it with her public key. That doesn't help keep it secret as anyone can now decrypt the message, but it does means anyone can prove that the message came from Alice.

If we want both, then we can both sign and encrypt the message:

when start

.set bobsPublicKey to "12827:349"

.set alicesPrivateKey to "19493:5609"

.set alicesPublicKey to "19493:89"

.

.ask "What's the message?" and wait

.set plaintext to answer

.

.set key to alicesPrivateKey

.tell cypher to "encrypt"

.

.set plaintext to cyphertext

.

.set key to bobsPublicKey

.tell cypher to "encrypt"

.say cyphertext

Alice first signs the message using her private key to prove its from her. Then encrypts with Bobs public key, so only he'll be able to read it. Note we do it this way round, so that only Bob can see that the message is from Alice (darn metadata again).

Then do decode and check:

when start

.set bobsPrivateKey to "12827:4549"

.set bobsPublicKey to "12827:349"

.set alicesPublicKey to "19493:89"

.

.ask "What's the encrypted message?" and wait

.set cyphertext to answer

.set key to bobsPrivateKey

.tell cipher to "decrypt"

.

.set cyphertext to plaintext

.

.set key to alicesPublicKey

.tell cipher to "decrypt"

.say plaintext

If we get a valid message at the end, then it must have been sent by Alice and can only be read by Bob. Rather than having "shared secrets" (as the saying goes, three people can keep a secret if two of them are dead), everything is either public (we assume everyone knows it) or private (only one person knows it).

When you connect to a secure website you use their public keys, so only they can read what you send them, and you send them your public key so they can send you data securely.

But is it really secure?

How can you give instructions for scrambling without someone smart being able to work those same steps backwards? It turns out its all based on prime numbers and clock arithmetic (or modulo arithmetic to give it its proper name). That maths is complex, but its based on a basic ideas.

Let's look at Bob's keys again:

.set bobsPrivateKey to "12827:4549"

.set bobsPublicKey to "12827:349"

The keys consist of two parts: the first is known as n, and its common to both bits. But its not just any number: its the product of two prime numbers. To generate a pair of keys we first generate two prime numbers, multiply them to get n, then use all three numbers to create the second parts of the keys.

Here's the trick: finding two prime numbers isn't too difficult, pick any two (7 and 17?). Multiplying them is easy (119). But what if I asked you what the factors of 119 were? Turns out that's a "hard" problem - or more accurately its believed to be a hard problem. Mathematicians and Computer Scientists have a very specific definition of "hard problem", which means something more than difficult - it basically comes down to saying the only solution is to try potential answers and see if they work. No one can prove that factoring is "hard" (that a way of doing it doesn't exist), but no one has shown it can be done efficiently either - RSA depends on this assumption.

If we know the original prime numbers then we can generate the keys. We then throw away those primes, knowing that without them we don't have enough information to calculate the private key from the public key, and there's no easy way to find them even though we know n.

So the security of RSA is dependant on how hard it is to factorise a number. If we want to crack Bobs messages we need to find two numbers that multiply to give 12827. That is (probably) "hard", but unfortunately its not actually that difficult if you've got a computer. A quick bit of googling turns up a websites that can do it, and if you've got a Pi, then Mathematica can solve it almost instantly.

We've done nothing wrong in theory but 12827 is just too small. A computer can try every possible factor almost instantly. We need a bigger number! The RSA16 device is a real implementation of RSA, and works great to demonstrate public key in action but it uses values of n that are up to 16bits in length. That's not enough to keep anyone out. You can try the RSA32 device which uses 32bit keys, but that's massively slower, and still way to small to be considered the slightest bit secure. Currently 2048 bits are required for even basic levels of security - computers are just really fast! 4096bits is a good idea if you're serious about this, and even 8192bits might be needed some time soon. Currently we don't have a Sniff RSA2048 device, so the RSA implemention is just "for fun".

The xxtea, rsa16 and rsa32 devices will be in Sniff Release 19, which should be available in a few weeks.

Sniff and the Picoboard

Working with the Arduino and Sniff makes it really easy for older children to plug together sensors, gather data and control motors. With a bit of planning, making sure you have the right parts and some pre-wired cables, you can make it so projects can be just plugged together.

However there's still a certain level of care and attention required that can make it harder of kids at younger age groups. That's why the lego Wedo is such a great tool - its about as kid friendly as it gets! It works with Scratch, so you can start with that, and then use the same hardware in Sniff.

The other common hardware used with Scratch is the Picoboard. It's provides a slider, a button, light and sound sensors, and 4 analog inputs for use with other resistive sensors (banana piano's and such). Now you can use that board with Sniff too. The code to use it is pretty simple:

make picoboard device

make picoSlider number

make picoLight number

make picoSound number

make picoRa number

make picoRb number

make picoRc number

make picoRd number

make picoButton boolean

when start

.forever

..tell picoboard to "update"

..if picoButton

...say join "Slider:" [picoSlider]

..wait 0.1 secs

Setup the board device, and create variables for each of the sensor inputs. Telling the board to "update", reads the values from all of the sensors. In this case we print out the position of the slider whenever the button is pressed down.

Before you run it you may need to help Sniff find the board. On Unix it should be found when you run setup. On Windows you need to tell it the com port that you want to use. Run setup as normal, then in the shell type something like:

export ARDUINODEV=COM3

depending on what com port your board is using.

All good, but what can we do with it?

Some guys I work with are involved with the LearnOMeter project. It's not a crazy idea: record environmental data from classrooms, try and find correlations with student progress. The gadget they built looks amazing. It's got a fancy 3d printed case, and measures a whole range of stuff, but I can't help feeling they've got a bit off track. The device is expensive, complex and hasn't collected a whole lot of data. Lets see if we can do better using a picoboard!

The board already has a light and a sound sensor. These aren't (as far as I know) calibrated in any meaningful way, so we can't say exactly how loud or how bright the room is, but we can track changes, which I think is far more interesting: how does noise level track through the day, as we engage in different activities? it doesn't matter exactly how loud it is - we just want to know about louder and quieter times.

We can use the picoboards external inputs to add additional sensors, provided we can find components who's resistance changes with the thing we want to measure. The easiest thing to add is another light sensor - a light dependant resistor (LDR) costs pennies, so I hooked one up across input A and pointed it out the window. That way I can see the relationship between outdoor brightness, indoor brightness and other factors. Does it get noisier when children can see a sunny playground outside?

Temperature is equally easy - we just need a Thermistor (again pennies on eBay - we can even get a waterproof one and use it to measure all sorts of things).  We just hook them up to the picoboard crocodile clicks and off we go!

For each of these we want a nominal resistance of around 10K to be compatible with the picoboard. We could do some maths to calculate the actual resistance of the component, and convert that into an actual lux/temp/RH value but its probably best to just log the data, and worry about it later.

make picoboard device

make picoSlider number

make picoLight number

make picoSound number

make picoRa number

make picoRb number

make picoRc number

make picoRd number

make picoButton boolean

make clock nativeClock device

make clockValue string

make fileSystem nativeFile device

make fileData string

make fileOK boolean

when start

.set fileData to "pico.csv"

.tell fileSystem to "startWrite"

.forever

..tell clock to "getDate"

..set fileData to clockValue

..set fileData to join fileData ","

..

..tell clock to "getTime"

..set fileData to join fileData clockValue

..set fileData to join fileData ","

..

..tell picoboard to "update"

..set fileData to join fileData [picoSlider]

..set fileData to join fileData ","

..set fileData to join fileData [picoLight]

..set fileData to join fileData ","

..set fileData to join fileData [picoSound]

..set fileData to join fileData ","

..set fileData to join fileData [picoRa]

..set fileData to join fileData ","

..set fileData to join fileData [picoRb]

..set fileData to join fileData ","

..set fileData to join fileData [picoRc]

..set fileData to join fileData ","

..set fileData to join fileData [picoRd]

..

..say fileData

..tell fileSystem to "writeString"

..

..wait 10 secs

This also gives us a chance to use the nativeClock and nativeFile devices (Sniff devices that include the word "native" mean they're running on a regular computer, which already knows how to handle that hardware so we don't need to - for example we could attach our own time keeping hardware, but the PC already has it build in).

To write a file we set fileData to the name of the file and "startWrite". From then on we can load a line of text into fileData and save it to that file with "writeString".

We use nativeClock to get the time and date, and join them together separated by commas. We then go on to add the values of the Slider, light, sound, and each of the resistance inputs. When we've made a full line of text we write it out, wait 10 seconds and go round again.

You'll note we record the slider position, even though that isn't going to tell us much about the actual environment... well part of the original spec for the learnometer was that it would be used to correlate "successful classroom outcomes" with environmental factors. There was lots of discussion about what exactly that meant, and how it could be recorded, but here's a simple solution. Someone moves the slider. If they're comfortable and happy they move it up, if they're not then they move it down. Who that someone should be and how often they need to move it I leave to the learnometer team, but we've got a mechanism when they figure it out.

Assuming you've got a picoboard and a computer, our version of the Learnometer costs about £1, and KS2 and above can build one in a few minutes. While it may not be as accurate, or complete, we could log data in hundreds of schools within a few weeks!

The data is written out in a format known as "csv", which means it can be loaded into any spreadsheet program. Lets go collect some data and I'll see what I got in a future blog.

Getting started with the ESP8266

For the last 6 months or so there's been a buzz in the underground hacker/maker/IoT community about a crazy new component that started to appear on AliExpress, and more recently on Ebay: the ESP8266, or its most common variant the ESP-01. At first the excitement was that for $5 we could get a simple to use, wifi board that could be easily hooked up to Arduino projects.

That was exciting, but as the community started to decipher the data sheets (available only in Chinese!) they realised it wasn't just a wifi board - it was controlled by a moderately powerful CPU, which included a boot loader that could refresh the firmware as easily as an Arduino. For $3 (current price!) the ESP01 provides a fully programmable embedded controller with wifi! By comparison the official Arduino Wifi shield is $70 (without host CPU), and other Arduino wifi solutions aren't much cheaper (for some reason Wifi is one area that the Arduino hasn't really competed well).

Once it became clear that it was possible to reprogram the ESP01, a port of Gcc quickly emerged, then someone packaged it into an Arduino plugin and developed Arduino compatable libraries. Adafruit now make a nice board using the chip, and are also supporting the Arduino IDE.

The ESP still isn't quite there yet in terms of either hardware or software - the hardware still needs bit of hacking together, and the software isn't quite optimised enough to run on the chip, but its real close, and we can expect the ESP to hit prime time over the next 12 months.

With that in mind I ordered a few and started experimenting with Sniff. There's still a way to go, but here's a summary of progress to date.

First of, some basics you need to know: The chip itself is the ESP8266. There are various boards available, typically known as ESP-01, ESP-02, ESP-03 etc... The only differences between these are the physical connections - which pins are accesable, and the type of connections used. The ESP01 has very limited pins exposed, but they standard 0.1" jumper spacing. The ESP201 has more pins available, and is a good choice, but the ESP01 is much more common and so cheap (£3.20 for two including shipping)  its the place everyone starts. Most of the other boards require some serious soldering to use, so you're on your own with them. Avoid the ESP-05 unless you simply want a wifi bridge, as it looks pin friendly (it is) but isn't reprogrammable.

ESP01 Hardware

The ESP01 is tiny! It's about 2cm by 1cm, which makes it a bit fiddly to work with. For a start there's no room for the board to label the connections! Fortunately this diagram makes things pretty clear:

There are 8 pins exposed.

Gnd/Vcc are pretty obvious, but Vcc needs to be 3.3v, and it needs a relatively hefty supply (250mA) to drive the wifi, so don't try powering it of an Arduino. Some people have had success with the regulators built into USB/serial adapters, but others report that they're unreliable. I wired up a separate 3.3v regulator (complete  boards to do this cost pennies on ebay).

3.3v is also pretty important for the serial. You need a 3.3v USB/serial adapter, and connect that to the UTXD and URXD pins to communicate with your computer (remember to connect the GND too, but not the Vcc). Don't use a 5V adapter (or connect these directly to a 5V arduino) or bad things might happen.

CH_PD is for powering down the board to save power - we don't care so connect it to 3.3v. RST can reset the board when its connected to 0v, but was can just leave it unconnected. It's possible to connect it to some of the lines on the Serial adapter to automatically reset the board, but I left it disconnected, and manually power cycle the board when needed.

This leaves GPIO0 and GPIO2. These are free for for you to use for your own hardware. That is a bit limited, but there's plenty you can do with just a couple of pins. If you need more then look at the ESP201. The important thing to know is that we can put the board into programming mode by connecting GPIO0 to GND when we power up/reset the chip.

It's quite possible to get all of this working with a load of jumper cables, but I wired up a dev system on protoboard. It includes the 3.3v regulator, a socket for a 3.3v ftdi usb/serial adapter, 3pin servo style headers on GPIO0 and 2, and a push to make reset button to ground GPIO0 for programming.

The ESP01 is socketed, so I can use this to easily program the board, then potentially install it in another circuit. To program I just power off the board, press the button and power on, then download the code from the computer.

Arduino Software

Now we need some software. The most up to date versions of the ESP8266 tools are available from ESP8266.com - the community site which is developing them. However things are moving fast and sometimes you need a more stable target. Adafruit are repackaging snapshots of the code, and adding support for their own boards, so you can find instructions for installing their version of the ESP tools on their website. Sniff is currently using the 1.6.2 version of the Adafruit Arduino ESP tools - newer versions might not work just yet. If you're reading this in the future, check the release notes for your version of Sniff to see which version of Arduino ESP is best.

You should now be able to fire the Arduino software and compile the standard blink example on an ESP01: Just plug everything in, select "generic ESP", and change the led pin to 2, and connect an LED(with resistor) to pin 2. Power down the ESP01, connect gpio0 to gnd, and power it back on. You can then disconnect the gpio0-gnd connect: it only needs to be connected at reset, and the board will stay in programming mode as long as you need it.

Then press download in the Arduino IDE, and it should just download and go!

Sniff

If you've got this far you're home free! Just setup Sniff as normal. If you're on Unix/Mac it will find the serial port (it will say its an Arduino - thats OK!). On Windows you'll need to type

export ARDUINODEV=COM3

or whichever COM port its been assigned.

Then just take the blink example, set the pin to 2, reset the board into programming mode, then compile and download it:

esp-sniff blink.sniff

Sniff should "just work" on the ESP as it does on an Arduino... There are some gotcha's however PWM isn't yet supported in the Adafruit Arduino software (it should be in the next release), and the current Arduino tools aren't particularly efficient - the generated code is far bigger than it needs to be. This is also expected to improve in the next Adafruit update. In the mean time, you're going to run out of memory quickly... sorry... it should get better!

With Sniff specifically digital inputs and digital outputs work. Analog input isn't possible on the ESP01, but should be possible on other ESP8266 boards. Analog output should work when Adafruit update their codebase. i2c works - it uses pins 0 and 2 simply because that's all that's available on the ESP01. SPI isn't possible with the ESP01 because there simply aren't enough pins. In future hardware SPI should be possible for the ESP201, but its a work in progress.

The key selling point of the ESP01 of course is its built in wifi. Sniff plays nice with the rest of the ESP libraries, so that the WIFI will power up and connect when Sniff code is running but we currently don't have any way to access it from Sniff yet. Once the ESP toolset stabalises and becomes efficient enough to make it viable we'll be able to get this working!

Conclusions

The ESP8266 isn't quite ready for prime time yet, but its getting lots in nominations for "best newcomer".  It's price and wifi support mean that it will be a big hit in the DIY "Internet of Things" space. Over the next few months, expect the tools to mature further to improve stability, features and code size. Also expect a rash of boards like the DigiSpark Oak. I'm sure someone will put an ESP in an Uno form factor before long!

We wanted to get Sniff running on these boards as soon as possible. Right now they're quite a bit more work and more limited than a simple Arduino solution, but imagine connecting a ds18b20 to gpio2 (tested and working!). Once the wifi is sorted, you can build a wifi enabled thermometer for less than £3!!!! Put one in each room and map out the heat movement in your house for a fraction of the cost of current systems! That IS exciting.

Release 18: Tabs Vs Dots

Sniff Release 18 is now available for download!

Its main features are:

• Initial Support for ESP8266
• Support for Arduino Software V1.6.4
• Support for Picoboard device
• Support for max LED Matrix display device
• Support for PS/2 Mouse device
• Tabs Vs Dots

Most obviously support for the ESP8266 is a really big step. It's a pretty great chip that does lots of stuff for very little money. Currently the tools and hardware for it are a little limited, so using Sniff with it isn't for the faint hearted, but we're expecting the resources to improve dramatically over the next 6 months, so there's a lot of potential there. We'll have a full post on the 8266 in the next few days.

As part of that we've revamped the way Sniff interacts with the Arduino software to use the latest and greatest Arduino V1.6.4. This particularly changes the way the Due is handled, as it needs to be installed as an additional component from inside the Arduino software. However the main takeaway from this for Sniff users is that now that the Arduino software is stabilising on a single version, rather than being split between the old 1.0, and 1.5 beta versions we no longer bundle a lot of supporting files, which makes the Sniff install much smaller.

We're really excited to have support for the Picoboard. While we initially had doubts about the cost effectiveness of this board, once we got it hooked up and running, we started to see the possibilites. Lots of schools have these to use with Scratch, so there's plenty of potential for re-using them with older kids. Again we'll post more on these in the next few days.

Finally dots vs tabs...

We think dots are a better way of doing indentation. They don't look pretty, but we think there's a fundamental problem with using white space as the basis of syntax - you can't see it. For example in Python "   " means something completely different to "    ". See the difference? No we can't either, but it really does matter. If you're looking at someone else's code (for example a room full of CS teachers in a cpd session looking at a python worksheet distributed by a national coding organisation...), then you'd better know that in the first case you should type 3 spaces, and in the second 4. To make it worse tabs and spaces look the same, but mean something different. Mix them up and your code looks identical, but behaves differently. Worse yet, they're not handled consistantly, so when I type tabs they may (or may not) get converted to spaces (or visa versa). Don't try copying code with tabs in from a regular website - it won't work!

We therefore chose dots. Not because we particularly like them, but because they're a non-whitespace character. You can clearly see how many there are so its possible to type example code correctly, and when you copy code/paste it stays the same.

However there's been a lot of comments that dots "look funny". As an experiment, we've therefore introduced support for tabs as indenting. Rather than using a dot, you can use a tab. We can't argue that it doesn't look better. It looks pretty, but its ambiguous and is dependant on having a workflow in place that will handle tabs constantly (for example I can't even type a tab in to this windows!).

We'll be sticking with dots for the foreseeable future for all the reasons we've outlined, but if you must start using tabs then try it and let us know how you get on. 

Downloads

Sniff Release 18 for Windows

Sniff Release 18 for Linux/Mac/Pi