Latest Event Updates

Has it been this long?

Posted on

Has it been this long since I made a blog post? wow.

I should maybe start writing again.

In the mean time I’ve made a nice simple Thermal Imaging Application for the CAT S60 phone.

Full Disclosure Mailing List Shutting Down

Posted on

Sadly, the last post on Full Disclosure mailing list was by John Cartwright stating that he is suspending the list indefinitely. He lists his reasons below:


When Len and I created the Full-Disclosure list way back in July 2002,
we knew that we’d have our fair share of legal troubles along the way.
We were right. To date we’ve had all sorts of requests to delete
things, requests not to delete things, and a variety of legal threats
both valid or otherwise. However, I always assumed that the turning
point would be a sweeping request for large-scale deletion of
information that some vendor or other had taken exception to.

I never imagined that request might come from a researcher within the
‘community’ itself (and I use that word loosely in modern times). But
today, having spent a fair amount of time dealing with complaints from
a particular individual (who shall remain nameless) I realised that
I’m done. The list has had its fair share of trolling, flooding,
furry porn, fake exploits and DoS attacks over the years, but none of
those things really affected the integrity of the list itself.
However, taking a virtual hatchet to the list archives on the whim of
an individual just doesn’t feel right. That ‘one of our own’ would
undermine the efforts of the last 12 years is really the straw that
broke the camel’s back.

I’m not willing to fight this fight any longer. It’s getting harder
to operate an open forum in today’s legal climate, let alone a
security-related one. There is no honour amongst hackers any more.
There is no real community. There is precious little skill. The
entire security game is becoming more and more regulated. This is all
a sign of things to come, and a reflection on the sad state of an
industry that should never have become an industry.

I’m suspending service indefinitely. Thanks for playing.

– John


Lets hope this is just a haox, or maybe the list comes back in another shape or form.

Easy String Encryption With Bouncy Castle and Jasypt

Posted on

At times you want a an easy and straightforward way to encrypt strings without the hassle of undocumented cryptographic libraries *cough* bouncy castle *cough*. This is where Jasypt comes in. It is a powerful encryption library that makes cryptography fun and easy! What makes Jasypt nice is that it can perform simple encryption using passwords very quickly. That is quickly in terms of development time.

Below is a simple example of using Jasypt to encrypt a string using BouncyCastle as the provider.

PooledPBEStringEncryptor encryptor = new PooledPBEStringEncryptor();
encryptor.setSaltGenerator(new RandomSaltGenerator());
String crypted = encryptor.encrypt("Hello World!");
String plain = encryptor.decrypt(crypted);

The above code should work, but you will need to download Jasypt and BouncyCastle libraries and set them on your classpath.

The Legion of the Bouncy Castle – Listing Public Key Certifications

Posted on Updated on

Instead of calling this post Part 6, I’ve decided to just give them nice and descriptive names from now on.

When managing your PGP Keys you often need to know who you trust and who you do not trust. All we need is the public key file (ASCII armored or binary). I have nested the operation in 3 different methods, mainly done for readability.

public void listPublicKeyCertifications() {
	String keysDir = System.getProperty("user.dir")+File.separator+"src/george/crypto/pgp/keys";
	File publicKeyFile = new File(keysDir+File.separator+"MrBilly.asc");
	try {
		System.out.println("The public key was certified by: ");	
		List<String> keyIds = listCertifications(publicKeyFile);
		for (String keyId : keyIds) {
	catch(Exception ex) {

public static final List<String> listCertifications(File publicKeyFile) throws IOException {
	FileInputStream keyInputStream = new FileInputStream(publicKeyFile);
	List<String> keyIds = getCertifications(keyInputStream);
	return keyIds;

private static final List<String> getCertifications(InputStream input) throws IOException
	List<String> keyIds = new ArrayList<String>();
	PGPPublicKeyRing pgpPubRing = new PGPPublicKeyRing(PGPUtil.getDecoderStream(input), new JcaKeyFingerprintCalculator());
	PGPPublicKey pubKey = pgpPubRing.getPublicKey();
	Iterator<PGPSignature> sigIter = pubKey.getSignatures();
	while(sigIter.hasNext()) {
		PGPSignature pgpSig =;
		long keyId = pgpSig.getKeyID();
	return keyIds;

Read the rest of this entry »

PGP Cryptography With The Legion of the Bouncy Castle – Part 5

Posted on

We’re back! Back to PGP Cryptography tutorials!! Because when I want to learn something new I learn faster by writing a tutorial about it, sharing code and receiving feedback.

So in Part 4 I apologized that I did not have a lot of time and just showed how to integrate Bouncy Castle with Android by using SpongyCastle. Now I will go through how to generate and verify detached signatures. This has become important since Part 2 did teach how to sign and verify files, but the signature was embedded inside the file. Though this works, it did not work when trying to verify the file using a regular program like GPG / Kleopatra. Also not all PGP clients support ZLIB compression which could break compatibility. So I decided that the need to generate detached signatures was important.

Continuing with the previous examples we have the PGPTools file which I wrote to make cryptography easier with BC (Full source can be found here). Generating a detached signature file needs the following:

  • The file you want to sign
  • The name of signature file that will be generated
  • The PGP Key ring that contains your secret and public keys

Another interesting thing to know to go by is the naming convention of these files. Most programs look for it and makes it easier for the user to utilize and for programs to find. Supposed there is a file called “TheFile.txt”, below is how the signature file would be named:

  • ASCII Armored Signature: TheFile.txt.asc
  • Binary Signature: TheFile.txt.sig

This is not mandatory, but a nice convention to follow.

Read the rest of this entry »

U.S. Nuke Silos Protected by Stupid All Zero Password

Posted on

The tile of this post says it all.

Please visit For Nearly Two Decades the Nuclear Launch Code at all Minuteman Silos in the United States Was 00000000 for more details.

I just cannot be bothered to write more about it, I hope they change it. I hope the Russians didn’t do anything this stupid as well.