full-disclosure - Re: Cipher detection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <12134.1302195827@localhost>
Date: Thu, 07 Apr 2011 13:03:47 -0400
From: Valdis.Kletnieks@...edu
To: Maksim.Filenko@...b.com
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Cipher detection

On Thu, 07 Apr 2011 11:22:56 +0300, Maksim.Filenko@...b.com said:

> I'm trying to figure out what kind of cipher was used in this:
> 
> GGobQ2bsqd64PXVAmaDiDBg=
> 
> Looks like Base64, but it's not. The original string is:
> 
> dummy@...mple.com

I'll place a bet (based on the trailing =), that in fact it *is* a base64
encoding of a ciphertext (remember, almost any good hashing or encrypting
function will produce random-looking binary data, and the only reason
that 'md5sum' produces a string of hex digits is because it was nice
enough to convert the binary output of the MD5 into something printable.

% echo GGobQ2bsqd64PXVAmaDiDBg= | base64 -d | od -cx
0000000 030   j 033   C   f 354 251 336 270   =   u   @ 231 240 342  \f
           6a18    431b    ec66    dea9    3db8    4075    a099    0ce2
0000020 030
           0018
0000021

Having said that, with *that* small a ciphertext and no other info, figuring
out the cipher will be next to impossible.  For instance, a perfectly plausible
answer would be "it has simply been xored with the hex string '7c1f762e
1fbccca6 d950052c fcbe8163'".  The fact that the input and output
strings are the same size means you can't even rely on data found in
the output for hints - there's no metadata encoded in the output to
leverage (like "a hex D3 at offset 27 means  the next 16 bytes are
SHA-256 output"), or "0x9901 at offset 0 means it's a GPG public
keyring".

Your best bet is to apply differential cryptanalysis.  We have one plain-cipher
pair.  Now try the following:

1) encode 'eummy@...mple.com' (one bit difference).  Is the output very
similar, and only different in 1-2 bytes? That would point to a simple xor or
substitution cipher.  If nearly half the bits change, then you're up against a
much stronger cipher.

2) Encode a null string if you can.  What pops out?  Encrypt the string
'dummy@...mple.co' (16 bytes).  Does that differ in the first 16 bytes of
output? Encrypt 'dummy@...ummy@ex' - if that produces 2 identical 8 byte output
blocks, the cipher blocksize is 8 bytes or 64 bits. Similarly, you can identify
if it's a 16 or 32 byte blocksize, and if they use block chaining at all or if
it's codebook time.

3) Check how bits propagate. Encrypt a string of all zeros, then a set of
strings with exactly one "on" bit.. x80.., x40.., x20, x10, x08 all the way
down to x01 (yes, for an 16byte string that's 128 times around).

Oh, and don't be afraid to cheat -  if you have access to the binary, run
'strings' on it, see if you get lucky and find a string like "ROT97 code by
MixMaster" or a function name that hints at the cipher (finding '3DESencode'
would be a hint, for instance. ;)

Content of type "application/pgp-signature" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/