How asymmetric signature works

In our daily life, when we say we sign a document, it means we put a signature on a document, and the signature is a drawing which the signer is the only one in the world who can re-create the same signature.  Same idea is applied in the digital world.  When we generate a digital signature, it means only the signer can generate this signature.  By verifying the singature, one can verify that the document is truly generated by the originator(not modified, not a fake from other source).

I'm trying to put this in simple English.  If you're looking for detail scientific equations, you can easily search elsewhere on the web. (https://en.wikipedia.org/wiki/Digital_signature)

Let me present a scenario.  I'm a FBI head and I'm sending a message to my FBI agent.  Say the message has nothing to encrypt, since it's already a code like "How's Billy?" and it means take action.  Say everybody can send this message to my FBI agent, but how can he know it's from me?  So we use asymmetric cryptograph(aka public key algorithm) for the digital signature.  Here is how it works:

First, I'll have to generate a pair of keys - public and private key. They're not the same key that's why we call it asymmetric cryptography.  If we're using the same key for encryption/decryption, or signature/verification, then it's called symmetric cryptography.  I will keep my private key private, as the definition of "private key".   If I lost my private key, my FBI agent dies.  So keeping private key private is very very VERY important.   I'll have to share my public key to my FBI agent.  How to share and make sure my FBI agent has my public key is another story.   The public key can be public, there is no secret in it, everybody can has it.  The only concern is that the key is legitimate. We don't want our FBI agent to has a wrong key.

Once the above step is setle, then I calculate a hash from my message; we usually call the hash result  a "digest".  It's called digest because a hash is taking any number of bits but always yields the same length of output, as if it doesn't matter how much we eat we always have a digest of same shxt.  Let's pick sha256 for this hash example, the has of the string "How's Billy?" is: b9f36ce69b818c46b23feea7f0b437c9f45bbf009cab333a4cc129a69fb7854a , then I use my private key to encrypt the above hash digest, and it's called a signature.  I'll send my message along with my signature.  My FBI agent receive the message and my signature.  He'll then first do the same sha256 has of my message "How's Billy?".  It should be b9f36ce69b818c46b23feea7f0b437c9f45bbf009cab333a4cc129a69fb7854a .
Then my FBI agent use his public key to decrypt(verify) the signature.  If the encrypted "signature" is the same as the has that he just calculated, then he verified that the message is truely from me.  Otherwise, the message must be from someone else because someone couldn't generate the signature properly(he couldn't generate the same "signature" without my private key, and guessing or hacking my private key is mathematically impractical/impossible).

Same scheme is used for software download.  Softwares are often mirrored or stored in different repositories.  Some can be corrupted or has virus(malware).   The above signature scheme is widely used in open source world to ensure authenticity of the software and also verify integrity(due to the nature of hash algorithm is integrity checking)

Build your own ARM cross toolchain from source

I used to have a mac and I want to use it for software development.  I need to build Linux kernel but I couldn't find the ARM cross compiler toolchain for OSX.  If you're in the same situation, you can follow below links to build you own toolchain:

• https://istarc.wordpress.com/2014/07/21/stm32f4-build-your-toolchain-from-scratch/
• http://jeremyherbert.net/get/stm32f4_getting_started

adding arm-none-eabi-gcc using Ubuntu ppa

If you're using Ubuntu apt, you can use the following command to install the
arm-none-eabi-gcc ARM cross compiler from ppa repository:

$ su
# apt-add-repository -y ppa:terry.guo/gcc-arm-embedded
# aptitude update
# apt-key adv --keyserver keyserver.ubuntu.com --recv-keys A3421AFB
# aptitude update
# apt-get install gcc-arm-none-eabi

and then when you type arm-none and tab, you should see the arm cross-compiler.

gideon@gideon-i5:~$ arm-none-eabi-
arm-none-eabi-addr2line   arm-none-eabi-gcc-4.9.3   arm-none-eabi-nm
arm-none-eabi-ar          arm-none-eabi-gcc-ar      arm-none-eabi-objcopy
arm-none-eabi-as          arm-none-eabi-gcc-nm      arm-none-eabi-objdump
arm-none-eabi-c++         arm-none-eabi-gcc-ranlib  arm-none-eabi-ranlib
arm-none-eabi-c++filt     arm-none-eabi-gcov        arm-none-eabi-readelf
arm-none-eabi-cpp         arm-none-eabi-gdb         arm-none-eabi-size
arm-none-eabi-elfedit     arm-none-eabi-gprof       arm-none-eabi-strings
arm-none-eabi-g++         arm-none-eabi-ld          arm-none-eabi-strip
arm-none-eabi-gcc         arm-none-eabi-ld.bfd 

Using ant to build Android sample code

It used to be so easy to build Android's code, now with Android Studio and gradle it become so complicated.

Let me put it down how to use ant to build before Google swipe everything away.  and this is the only way to build their sample code now since many sample codes are not migrated to Android Studio and gradle/gradlew yet.

• go to sample code root directory.  android-21 is the target API, the command will generate build.xml for build process
  $ android update project --target android-21 --path .
• build the debug apk
  $ ant debug
• use find . -name *.apk to locate the apk file.  use adb to install apk to your phone
  $ adb install ./bin/NewsReaderActivity-debug.apk

Summary:

1. $ android update project --target android-21 --path .
2. $ ant debug
3. $ adb install ./bin/NewsReaderActivity-debug.apk

Simple as that!

Typing Chinese in English Ubuntu 14.04

1. Open Terminal


2. aptitude install scim scim-tables-zh  (and dependencies)
3. Logout or restart
4. right-click input area and select "Input Methods", change from "X input Method" to "SCIM Input Method".


5. Ctrl-spacebar should give you a scim toolbar

**

Update:

scim seems to be a soon obsoleted input method and it crashed on Chrome while I was running in 14.04.  Now I tried ibus and it seems to work pretty well (yet).  

• In "Language Support", select "IBus" in Keyboard input methold system.
• Install / Remove Languages... select traditional Chinese
• In "Text Entry", click "+" to add Input sources (Chinese (cangjie3)
• In "Input Method", choose IBus
• change the keyboard shortcut, my own preference is Ctrl+Space
• make sure to check the box "Show current input source in the menu bar"

You probably need to logout/login to take IBus in effect

screen and nohup

Not long ago, I introduced nohup to let a program continue executing after you exit or logout from your ssh session..

then not long after that, I introduced screen for UART/COM/serial communication

then I found out, using "screen" is a much wiser choice.
Simply flow are as follow:

1. create a screen
2. execute whatever you want to run, probably something like a server
3. detect a screen (ctrl-a, d)

There you go. Server will continue to listen after you log off your ssh session.

In case you want to go back to that screen, just re-attach it

1. list screen (screen -ls)
2. re-attached the screen (screen -r [screen name])
3. there, ctrl -c to quite your program or server or whatever, then type exit to exit the screen

Displaying remote X clients

This will allow you to ssh to a server and prompt x windows:

$ export DISPLAY=:0.0

and

$ ssh -Y username@remove_server_ip

Remember the -Y option, it enables trusted X11 forwarding.

OSX UART serial terminal

In OSX, turn on the terminal, plug in your FTDI USB-serial dongle, you should see a new usbserial device created under /dev.  Use "screen" to start the session, remember to state the baudrate at the end of the command:

$ screen /dev/cu.usbserial-FTVLVQ6M 115200

To detach:

Ctrl-a d

To re-attach:

$ screen -r

To kill the screen:

Ctrl-a k

difference between insmod and modprobe

Time to refresh memory:

modprobe reads the modules and its dependencies from /lib/modules/$(uname -r)/modules.dep or modules.dep.bin.  modprobe is a smarter tool which will also load the dependent modules.

modprobe accepts the name of a .ko file in /lib/modules/$(uname -r) and aliases (modules.alias.bin).

insmod takes file name or the exact paths to files. The module does not have to reside in /lib/modules/$(uname -r), but dependencies are not automatically loaded. This is the lower program used by modprobe to load modules.

rmmod removes a kernel name based on the name from /proc/modules. This name does not necessarily have to be the same as the one passed to modprobe (for the nvidia-current file, this is nvidia for example).

modinfo accepts a filename, or the filename without .ko suffix in /lib/modules/$(uname -r).

guake - a cool top down terminal for Gnome

http://guake.org/

It's just cool....
try it:

# sudo aptitude install guake