Seems like there's a risk that Posterous might end up shutting down.So to replace it I want to get my own domain so that I can have a permanent place online.Any suggestions for registrars and hosts, etc?
Edit: My current blog: http://roamingaroundatrandom.wordpress.com/
torsdag 15 mars 2012
torsdag 8 mars 2012
How to uninstall Digime on N9
The steps:
Enable developer mode, open the terminal (it shows up in the launcher), enter this: "cd /etc/init/apps" and hit enter/newline (that big button on the bottom right of the keyboard :). Then enter "ls", then look for the name of this app's script there. Then you run "devel-su", enter the password (default is "rootme", change it or disable developer mode afterwards!), and after that you run "mv name-of-the-digime-script /home/user/" (this moves it instead of deleting it). Now, REBOOT! Now you can uninstall the app!
Just thought I'd share that here.
fredag 30 december 2011
Fun with WordFeud - part 2
I'd be impressed if he even takes the challenge. I would have resigned right away after complaining about cheating. ;)
- Sent from my phone
måndag 5 december 2011
fredag 11 november 2011
Binary day, 11-11-11
No matter what date format you prefer (except for those with the year in four numbers), today's date is a binary date (only 1's and/or 0's). Yesterday was another one. And this one is actually the last of this century, since there won't be another year ending in only 1's and/or 0's until 2100.
Just thought you might be interested. :)
onsdag 9 november 2011
Number of apps
Some people have 55 apps on their phones. This morning I had 55 apps *waiting for updates*. Total app count? Over 300.
Fortunately my SGS have room for them all, unlike my old Spica that almost always had out-of-space warnings when I installed new apps.
Among the updates were the newest version of mAnalytics - and it's great!
There were also an update of Google Goggles, but I don't really feel like using it's new autosearch feature for camera pictures. Feels creepy, kind of. And it's also not accurate enough.
I might write a bit more about my apps later, but for now this is all.
lördag 11 juni 2011
Photos: Øresundsbron
Well, we usually don't use the ø-character over here, we call it Öresundsbron on this side of the border. But most signs and the advertisement for it use the ø-character. Do the Danish maybe use the ö-character for it (and do I have any Danish readers that can answer that question)?
Also, do you like my photos of it from beneath?
söndag 29 maj 2011
Some thoughts about steganography
Here's a steganography method I've been thinking about today:Let's say you have plaintext A to hide. You have something to hide it in, we'll call it medium B (preferably lossy, but hiding it in audio WAV audio files works just fine while JPG images often might be preferred).
You generate key C to protect it. You do this by picking a strong password and running this trough a one-way checksum generator. SHA256 is a good choice if you're going to use AES with 256 bit encryption.
If A is a text file, you should compress it. Bzip2 is a good choice, IMHO. Then you encrypt it with key C and a symmetric encryption algorithm like AES, giving you the ciphertext.
Then you generate an error correction code for the encrypted data becaue it makes it a bit more resistant against modifications.
Then you encrypt the error correction code with the same key C. (Yes, this means that if there's damage to the error correction code in the image you have lost the ability to get easy verification.)
Now you append the the encrypted error correction code to the ciphertext.
This is then hidden in your medium B using key C as a key, once again. Yes, this means that if you use a poor steganography algorithm that the key can be extracted from if all you got is the medium, then your encryption method is broken too. When extracting the data you use the same key C to get the ciphertext and encrypted error correction code. Then you decrypt the error correction code and verify the ciphertext. Then you decrypt the ciphertext and get the hidden data. If you used an encryption algorithm that does not have a "waterfall effect" on the error correction data, you would not loose the entire error correction data due to a small error in it.
(This would mean not using AES, but potentially just XOR:ing the error correction data with the key. Beware of any encryption method that is weak to cryptoanalysis! Also, beware of steganography methods that let attackers calculate your key!)
If using an encryption method where bits are encrypted one by one or only in small chunks that doesn't effect the rest of the encrypted data, it could allow a JPG image to be recompressed and the data would be recoverable, despite being encrypted and seemingly random to begin with. Depending on the sixe of the image and the data, the data could survive almost unimaginable alterations. With 1000% error correction data (10 bits of reduntant data for every bit of actual data - Qr codes use 30%, 3 extra bits per 10 bits of data) and a 20 megapixel image, a couple of lines of text could easily be hidden and survive many recompressions and alterations. The data could potentially be recoverable if you printed the picture and took a photo of it and then tried to recover the data from that.
Encrypting the error correction code prevents an attacker from being able to easily confirm if he has found the hidden ciphertext or not in an image.So what's the point with all this? Nothing, really. It's just interesting to me. I'd like to try implementing this myself some day (with existing algorithms of course, sine I'm lazy ;).
It would be fun to print an image and take a photo of it and still be able to recover he hidden data.
You generate key C to protect it. You do this by picking a strong password and running this trough a one-way checksum generator. SHA256 is a good choice if you're going to use AES with 256 bit encryption.
If A is a text file, you should compress it. Bzip2 is a good choice, IMHO. Then you encrypt it with key C and a symmetric encryption algorithm like AES, giving you the ciphertext.
Then you generate an error correction code for the encrypted data becaue it makes it a bit more resistant against modifications.
Then you encrypt the error correction code with the same key C. (Yes, this means that if there's damage to the error correction code in the image you have lost the ability to get easy verification.)
Now you append the the encrypted error correction code to the ciphertext.
This is then hidden in your medium B using key C as a key, once again. Yes, this means that if you use a poor steganography algorithm that the key can be extracted from if all you got is the medium, then your encryption method is broken too. When extracting the data you use the same key C to get the ciphertext and encrypted error correction code. Then you decrypt the error correction code and verify the ciphertext. Then you decrypt the ciphertext and get the hidden data. If you used an encryption algorithm that does not have a "waterfall effect" on the error correction data, you would not loose the entire error correction data due to a small error in it.
(This would mean not using AES, but potentially just XOR:ing the error correction data with the key. Beware of any encryption method that is weak to cryptoanalysis! Also, beware of steganography methods that let attackers calculate your key!)
If using an encryption method where bits are encrypted one by one or only in small chunks that doesn't effect the rest of the encrypted data, it could allow a JPG image to be recompressed and the data would be recoverable, despite being encrypted and seemingly random to begin with. Depending on the sixe of the image and the data, the data could survive almost unimaginable alterations. With 1000% error correction data (10 bits of reduntant data for every bit of actual data - Qr codes use 30%, 3 extra bits per 10 bits of data) and a 20 megapixel image, a couple of lines of text could easily be hidden and survive many recompressions and alterations. The data could potentially be recoverable if you printed the picture and took a photo of it and then tried to recover the data from that.
Encrypting the error correction code prevents an attacker from being able to easily confirm if he has found the hidden ciphertext or not in an image.So what's the point with all this? Nothing, really. It's just interesting to me. I'd like to try implementing this myself some day (with existing algorithms of course, sine I'm lazy ;).
It would be fun to print an image and take a photo of it and still be able to recover he hidden data.
fredag 15 april 2011
Turning Torso photo
I really wish I had a better camera. Maybe a Nokia N8 (those phones have amazing cameras). I should get a proper quality camera some day. I know I can find some pretty good angles for photos, but with the cameras I have access to it's rarely worth it.
- Sent from my phone
torsdag 31 mars 2011
Quick review: Tesla Plushies (Android game)
There you have the intro video for this fun and challenging Android game. I have beaten all levels except level hard #13. It often takes several tries to figure out how to make the plushies behave the way you want.
Once you have learned the game physics it becomes more of a fun challenge and spare time killer then a plain frustrating time waster.
If you have an Android, try it out now!
http://market.android.com/details?id=com.bithack.teslaplushies
Prenumerera på:
Inlägg (Atom)