Dirt cheap steganography

This steg module is based on code, ideas and images from http://blog.wolfram.com/2010/07/08/doing-spy-stuff-with-mathematica/ .
It requires numpy & matplotlib but can be reworked to depend on pypng instead of matplotlib

Sample usage

$ python2.7 simple_decode.py --help

Usage:

Hide/Unhide info in images as described in this post:

http://blog.wolfram.com/2010/07/08/doing-spy-stuff-with-mathematica/

usage: simple_decode.py [options]

Options:

-h, --help show this help message and exit

-v DEBUG, --verbose=DEBUG

Debug. Higher integers increases verbosity

-e ENCODED_FILE, --encoded_file=ENCODED_FILE

Encoded PNG file to work with. Default is

steg_chicken_secret.png

-d DATA_FILE, --data_file=DATA_FILE

File with decoded data or with data to encode.

Example decode of data hidden in the wolfram blog images

$ python2.7 simple_decode.py -e steg_chicken_secret.png -d chicken.txt
$ cat chicken.txt ;echo

This is a secret message.



$ python2.7 simple_decode.py -e alice.png -d alice.txt

$ file alice.txt

alice.txt: UTF-8 Unicode English text, with very long lines, with no line terminators



$ python2.7 simple_decode.py -e finalImage.png -d data.jpg

$ file data.jpg

data.jpg: JPEG image data, JFIF standard 1.01, comment: "Created by Wolfram Mathematica "

RPKI tools

An ISC implementation of the RPKI drafts can be found here http://www.rpki.net/.
Since all objects published in RPKI repository are in ASN1, dumpasn1 can be used to quickly peek at the objects. Here's an example.

Sample asn1 dump

RPKI Products: ROA

Current described by this draft, Route Origin Authorizations (ROAs) associate an AS number and a list prefixes in an object which is then CMS signed by a the owner of the prefixes. By generating a ROA, the owner of the prefix is stating that the as number in the ROA is allowed to originate the prefixes listed in the ROA. Third parties can then fetch ROAs, verify their cms signature and then use validation rules as per http://tools.ietf.org/wg/sidr/draft-ietf-sidr-roa-validation/. ROAs encapsulate end entity certificates within them. A sample ROA is shown below.

Sample ROA

RPKI Manifests

Manifests are currently documented by this sidr draft. Manifest are signed objects that have a list of all the objects in a repository (except the manifest itself) and their corresponding hash. A valid manifest helps to ascertain that the objects in a publication point are fresh (latest issued) and complete i.e. none are missing.
Similar to ROAs, manifests embed an End Entity (EE) which enforces the manifest validity period. A sample manifest is shown below.

Sample Manifest

RPKI CRLs

Each engine (rpki instance with a certificate) is expected to maintain an update to date CRL that is generated at regular intervals. The CRL records any keys revoked due to product expiry or security incidences. Each certificate points to it's parent CRL by using the X509v3 CRL Distribution Points attribute (It's the parent that issued a certificate. Consequently, revocation responsibility lies with the parent).
An example CRL is shown below. The important bits:

• Authority Key Identifier and Issuer point to the issuer (certificate in previous article).
• CRL number which is incremented with each issue.
• Last update and next update time constraints.
• Revocation number and date of each certificate identified by a serial number. 

Sample CRL

Certificate fingerprints

If you have self signed certs, you may run across some programs that require you to include the fingerprint of the remote server cert somewhere in your config.
An example application is mercurial (as shown below):

$ hg clone https://a.b.c.net/public/application/
abort: error: _ssl.c:497: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

The fix is easy:
Get the server certificate fingerprint (sha1 fingerprint of certificate)

$ echo quit |openssl s_client -connecta.b.c.net:443  2>/dev/null|awk '/---BEG/,/--END/' |openssl x509 -fingerprint -noout
SHA1 Fingerprint=69:C7:E4:E7:10:F8:8F:19:F9:5D:92:F3:8D:EC:CF:4F:7B:3E:04:0A

Then edit your ~/.hgrc

...
 [hostfingerprints]
a.b.c.net = 69:C7:E4:E7:10:F8:8F:19:F9:5D:92:F3:8D:EC:CF:4F:7B:3E:04:0A                                            
.....

That should fix things up.

Same thing can be done for fetchmail:

$ echo quit |openssl s_client -connect mail.xyz.net:143 -starttls imap 2>/dev/null|awk '/---BEG/,/--END/' |openssl x509 -md5 -fingerprint -noout
MD5 Fingerprint=AA:87:67:1A:21:16:50:57:3F:6C:D0:C8:E8:02:19:7C

then fixing your ~/.fetchmailrc

poll mail.xyz.net protocol imap
        user "user1" password "somepass123"       
        sslfingerprint  "AA:87:67:1A:21:16:50:57:3F:6C:D0:C8:E8:02:19:7C"                                                    
        mda "/usr/bin/procmail -d %T "