simple pipe using crazy/crappy crypto for encryption and signing
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
cod
common
crypto
sig
Makefile
NEWS
README
VERSION
c3maint.pub

README

cr^3 - crazy-crappy-crypto

implements two simple pipes using:
 - rsa and keccak-based spongewrap authenticated encryption
 - highly experimental post-quantum signatures based on keccak and
   sphincs256

(C) 2015 by stf, <s@ctrlc.hu>, GPLv3

why crazy-crappy-crypto? it's crazy because it uses unsanctioned,
experimental and unconventional crypto implementations, some of which
are so fresh, that it's not even a month that the paper has last been
edited on which some of this is based. None of these tools should not
find wide adoption within at least the next 5-10 years. The selection
of the algorithms is conservative in the way, that besides fresh algos
the rest is selected either on maturity or has at least been
considered in a crypto contest in the final round. Crappy is the way
some of this is implemented, the crypto algorithms are simply ripped
out from other projects, like the supercop benchmarking
suite. Although some have been verified to provide the expected test
vectors, otherwise not much effort has been done to verify the
resistance against various attacks on any of these implementations. so
anyone to use this crap must be crazy, hence the name.

WARNING - these tools should only be used by people who want to break
these tools and publish their results. Any damages, liabilites, etc
are waived. DO NOT use these for anything else but breaking them. It is
crazy and irresponsible to use these tools for anything serious. You
have been warned.

COD - the authenticated encrypted asymmetric pipe.

useful at least in the following use-case: you have some receiving
device on which plaintext data arrives, which you want to encrypt
before it is forwarded in a hostile environment to the final recipient
holding a private key in a safe location. In this one-way setting the
recipient is never talking to the host doing the encryption. The main
threat this tool counters is the seizure of the data after reception
on the receiving device until safe delivery to the final destination.
Combine it in-depth with other defenses.

Example: take photos in a hostile environment, encrypt the the photos
and be unable to recover them until arrival in the save location with
the the private key. (note, this does not protect against forensic
attacks against the storage device - maybe copying the encrypted and
destroying the original device with plaintext residue is the only and
expensive way)

crypto: a random 32 byte message key is encrypted with the public
key of the recipient in oaep padded RSA, then this message key is
fed into SpongeWrap, which is then used to authenticated encrypt the
message.

output format:
   2 bytes - the length of the RSA encrypted message key in network
             byte order
   n  bytes - the RSA encrypted message key
   m  bytes - the encrypted message (usually as big as your RSA key)
   16 bytes - the "MAC"

message overhead is 530 bytes with a 4096 RSA key.

Install
depends: openssl seccomp

`make install`

If you don't want to support encrypted private keys, set

`make install WITHOUT_PASSWORDS=y`

if you do not have/want seccomp-based sandboxing:

`make install WITHOUT_SECCOMP=y`

create keys using openssl:
$ openssl genrsa -out my.key 4096
$ openssl rsa -in my.key -pubout >> my.pub

deploy my.pub on the encrypting host, secure my.key in a safe
location for decryption.

test with: `make test` or something similar:

$ for i in {0..42} {8170..8210} 1000000; do
      echo -ne "\r$i   "
      dd if=/dev/zero bs=$i count=1 2>/dev/null |
           ./cod e my.pub |
           ./cod d my.key >/dev/null ||
           break
  done

or test with:

$ ./cod e mx.pub <cod.c | ./cod d mx.key | md5sum; md5sum cod.c

if the secret key is encrypted, then supply the password as value in
the COD_PASSWORD environment variable to the decrypt operation:

$ ./cod e mx.pub <cod.c | \
      COD_PASSWORD="mysecretpassword" ./cod d mx.key | \
      md5sum; md5sum cod.c

if you supply a password, you should make sure that 1/ you have no
shell history or 2/ you have it well protected.

-------------------------------------------------------------------------

sphincs - post-quantum signature pipe

WARNING: this is very experimental and unsanctioned stuff, don't use
it for anything non-nefarious.

useful in any crypto graphic siging-scenario where 41kB signatures are
acceptable.

Example: the source code of cr3 is signed with sphincs.
you can verify it by running:

$ cat cr3-${cr3version}.txz cr3-${cr3version}.txz.sig | sphincs v c3maint.pub >/dev/null

you can find the c3maint.pub key in this source archive, and you can
get the signature for v0.3.1 from:
   https://www.ctrlc.hu/~stef/cr3-0.3.1.tar.gz.sig

try it like this:

$ { curl -Lqs 'https://github.com/stef/cr3/archive/v0.3.1.tar.gz' |
        tee cr3-0.3.1.tar.gz # save a copy of the archive
    curl -qs 'https://www.ctrlc.hu/~stef/cr3-0.3.1.tar.gz.sig' } |
    ./sphincs v ./c3maint.pub >/dev/null ||
        rm cr3-0.3.1.tar.gz # remove archive if signature fails

Crypto: the incoming message is hashed with keccak512 and this hash sum
is signed with sphincs256.

Output format: the pipe copies the incoming stream verbatim to
standard output with the sphincs256 signature appended. The signature
size is currently: 41000 bytes.

Install
depends: seccomp

`make install`

if you do not have/want seccomp-based sandboxing:

`make install WITHOUT_SECCOMP=y`

create keys:
$ ./sphincs g /tmp/mykey

publish /tmp/mykey.pub among your verifiers, secure /tmp/mykey.key in
a safe location for signing.

test with: `make test` or something similar:

$ echo 'It works' | ./sphincs s /tmp/mykey.pub | ./sphincs v /tmp/mykey.key

---------------------------------------------------------------------------

Sandboxing

These tools all come with seccomp-based sandboxes, although they have
not been exposed to many systems, so it might happen that the sandbox
kills your process. In this case recompile the tools using

    $ make WITHOUT_SECCOMP=y

run them with uninteresting data through:

    $ strace -fo /tmp/misbehavingsandbox <command....>

and 1/ fix it yourself and send a patch, or 2/ send me the file
/tmp/misbehavingsandbox. Thanks in any case, and sorry for the
inconvenience. In the mean time you can use the tools without
sandboxing by using `make WITHOUT_SECCOMP=y` to recompile.