Question about esubs
George Orwell
actual subject, is the esub always the same (since the
subject doesn't change) or does it somehow come out
different each time?
Il mittente di questo messaggio|The sender address of this
non corrisponde ad un utente |message is not related to a real
reale ma all'indirizzo fittizio|person but to a fake address of an
di un sistema anonimizzatore |anonymous system
Per maggiori informazioni |For more info
https://www.mixmaster.it
Dave U. Random
> When an nym is setup to create an esub in place of your
> actual subject, is the esub always the same (since the
> subject doesn't change) or does it somehow come out
> different each time?
Different.
Zax
Hash: SHA512
On Sun, 1 Nov 2009 20:29:38 +0100 (CET), George Orwell wrote in
Message-Id: <e085d287a5ad0ce0...@mixmaster.it>:
> When an nym is setup to create an esub in place of your
> actual subject, is the esub always the same (since the
> subject doesn't change) or does it somehow come out
> different each time?
It looks different every time. The first 64 bits of the esub (16 hex
digits) are random. This random number is used to seed the encryption
used in the remaining digits of the esub. The result is that the whole
thing looks random. To validate it, you need three items of info; the
original subject, the encrypt key and the publicly known random number.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEAREKAAYFAkruyYQACgkQlKZ6CY7Vd0Nl2gCgmNs613uH9w6Uy2LPIZt5B68Z
x/MAnRsiMmb0T/pigU2+8ObCmsuwKWDP
=2+eV
-----END PGP SIGNATURE-----
--
pub 1024D/8ED57743 2003-07-08 Bananasplit Operator
Key fingerprint = 796F 67E0 E890 A0BB BDAE EBB4 94A6 7A09 8ED5 7743
uid Admin <admin.bananasplit.info>
Nomen Nescio
>digits) are random. This random number is used to seed the encryption
>used in the remaining digits of the esub. The result is that the whole
>thing looks random. To validate it, you need three items of info; the
>original subject, the encrypt key and the publicly known random number.
So, does this mean that the unencrypted subject line can only be
32 bytes long? (48 - 16, or is that 16 bytes long?)
Zax
Hash: SHA512
On Tue, 3 Nov 2009 05:50:17 +0100 (CET), Nomen Nescio wrote in
Message-Id: <1186b948273ab1f0...@dizum.com>:
> So, does this mean that the unencrypted subject line can only be
> 32 bytes long? (48 - 16, or is that 16 bytes long?)
The Subject can be of any length. It's hashed using MD5 to produce 16
Bytes (32 hex digits). Add to that the 8 Byte random number (16 hex
digits) and you get the 48 digit eSub.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEAREKAAYFAkrwcIEACgkQlKZ6CY7Vd0PZHwCcCU6uTFYQ5LnsktA+Wfq7iBI9
TI4AoJSryp0f+ou0+1TlQeWYpSFIizRs
=mPs3
Dave U. Random
> So, does this mean that the unencrypted subject line can only be
>32 bytes long? (48 - 16, or is that 16 bytes long?)
>The Subject can be of any length. It's hashed using MD5 to produce 16
>Bytes (32 hex digits). Add to that the 8 Byte random number (16 hex
>digits) and you get the 48 digit eSub.
So, I am assuming that a finder program like aamfetch discovers your
messages by taking your known subject, attachs your esub key to the
its end, and then attaches that string to the end of the 8 byte random
number from each downloaded aam subject, and then does an MD5 on all
of this to see if it matches the last 16 hex bytes of the aam news
subject.
Do I have the sequence right?
(1st 8 byte random number from each aam message subject + your known
subject + your esub key, then this string MD5ed to see if it matches
the last 16 hex bytes of the subject)
Zax
Hash: SHA512
On Thu, 5 Nov 2009 06:13:27 +0100 (CET), Dave U Random wrote in
Message-Id: <63230fb97897fe10...@anonymitaet-im-inter.net>:
> So, I am assuming that a finder program like aamfetch discovers your
> messages by taking your known subject, attachs your esub key to the
> its end, and then attaches that string to the end of the 8 byte random
> number from each downloaded aam subject, and then does an MD5 on all
> of this to see if it matches the last 16 hex bytes of the aam news
> subject.
The finder program works by generating an esub, just like the remailer
that sent the message. The only difference is that the remailer
generated an 8 Byte random number but the finder doesn't. It uses the
random number within the esub it's checking.
To generate the esub, the server needs:
The Subject
The Encrypt-Key
An 8 Byte Random Number
To match the esub, the finder needs:
The Subject
The Encrypt-Key
The 8 Byte Random Number generated by the server.
When the finder generates an esub using identical variables as the
server, the resulting esub will be identical.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEAREKAAYFAkrynlAACgkQlKZ6CY7Vd0OijQCfcLQPjJKt1F0qLaH8MeIgU+jD
Am4AoKq2EGxNBrCDkAR3+bKxR3gwM+4r
=VV+A
Fritz Wuehler
> To generate the esub, the server needs:
> The Subject
> The Encrypt-Key
> An 8 Byte Random Number
>
> To match the esub, the finder needs:
> The Subject
> The Encrypt-Key
> The 8 Byte Random Number generated by the server.
Where does the "finder" get the 8 byte random number? Can you please list
the steps to create and then match your own esub thanks.
Zax
Hash: SHA512
On Thu, 05 Nov 2009 21:34:05 +0100, Fritz Wuehler wrote in
Message-Id: <60a7944ec649a05d...@msgid.frell.theremailer.net>:
> Where does the "finder" get the 8 byte random number?
It's the first 16 digits of the esub its checking.
> Can you please list the steps to create and then match your own esub
> thanks.
Check out http://www.bananasplit.info/esub.py
It's a Python script for generating and checking esub's. Even if you
don't know Python, it should be possible to follow the steps involved.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEAREKAAYFAkrzOrgACgkQlKZ6CY7Vd0NlUwCgoWdxuqERVz9nyjx6I8qdkw/p
UPkAoJtVWLVo98IDQV8YUCPoYJIPO5Ea
=co5e
Fritz Wuehler
>It's the first 16 digits of the esub its checking.
>Can you please list the steps to create and then match your own esub
>thanks.
>Check out http://www.bananasplit.info/esub.py
>It's a Python script for generating and checking esub's. Even if you
>don't know Python, it should be possible to follow the steps involved.
I'm lost! I'm lost!
Nomen Nescio
> So, does this mean that the unencrypted subject line can only be
>32 bytes long? (48 - 16, or is that 16 bytes long?)
>The Subject can be of any length. It's hashed using MD5 to produce 16
>Bytes (32 hex digits). Add to that the 8 Byte random number (16 hex
>digits) and you get the 48 digit eSub.
So, I am assuming that a finder program like aamfetch discovers your
messages by taking your known subject, attachs your esub key to the
its end, and then attaches that string to the end of the 8 byte random
number from each downloaded aam subject, and then does an MD5 on all
of this to see if it matches that aam news subject.
Do I have the sequence right?
(1st 8 byte random number from each aam message subject + your known
subject + your esub key, then this string MD5ed to see if it matches
the last 16 hex bytes of the subject)
StealthMonger
Hash: SHA1
Fritz Wuehler <fr...@spamexpire-200911.rodent.frell.theremailer.net>
writes:
> I'm lost! I'm lost!
Appended below is the man page and C code for esubbf. esub is the
same except that it uses (patented) IDEA instead of Blowfish.
-- StealthMonger
<Stealt...@nym.mixmin.net>
--
stealthmail: Scripts to hide whether you're doing email, or when,
or with whom.
mailto:stealt...@nym.mixmin.net
Finger for key.
ESUBBF(1)
NAME
esubbf, esubbft, esubbft-arthdr <-> compute or test an encrypted subject
SYNOPSIS
esubbf key subject
esubbft key subject esub
esubbft-arthdr key subject
DESCRIPTION
Compute or test a so-called "encrypted subject" for use in a news arti-
cle posted on USENET newsgroup alt.anonymous.messages. This is random-
looking 48-digit hexadecimal number which is supposed to be efficiently
recognizable, but only with knowledge of the subject and key.
These programs are intended for use in shell scripts and would rarely
be used interactively from the keyboard.
For all three programs, subject and key are the subject to encrypt and
the key with which to encrypt it.
esubbf computes and writes to stdout an encrypted subject using the
given subject and key plus a crytographically-strong random number.
esubbft tests the given encrypted subject esub and returns success code
0 if esub could have resulted from the given subject and key, else it
returns failure code 1.
esubbft-arthdr is a simple script which applies esubbft to the content
of the first Subject: line found on stdin. It is useful as a test in a
procmail(1) script.
The algorithm for computing an encrypted subject is identical with that
of the "classic" esub (see HISTORY below) except that it uses Blowfish
encryption instead of IDEA (which is patented). The 48-digit encrypted
subject encodes a 64-bit random IV followed by the 128-bit result of
encrypt(subject,key,IV). The intention is that it not be feasible to
determine subject or key from esub, or to determine if two esubs could
have resulted from the same subject and key.
HISTORY
"Encrypt Subject" was discussed by Andy Dustman in 1997 on the remailer
operators mailing list. He wrote that "it allows you to encrypt a hash
of the subject using a secret key, thus making the subject appear to be
a random-looking string of 48 hex digits which is different each time
(due to IDEA-CFB encryption). It's intended for nym reply blocks which
point to alt.anonymous.messages." By 1999 it had been incorporated by
RProcess into the widely-used Reliable remailer. See
http://www.skuz.net/potatoware/esubplug.html. An error in an early
implementation was worked out on the remailer operators mailing list in
dialogue between RProcess and Ulf in 1999. A noteworthy remark by Ulf
at this time was "The idea of esub is that each message has a different
Subject header and only the person with the key can check which ones
belong together."
Working from these sources, the present author ported the algorithm
back to its original Unix platform in 2003 for use in pseudonym reply
blocks to alt.anonymous.messages. The recent introduction of stealth-
mail(7), a new application having no need to be interoperable, was a
fine opportunity to break with the original patented IDEA implementa-
tion. blowfish(3) was chosen as the replacement because of the avail-
ability of BF_cfb64_encrypt(3), which is the mode of the original IDEA
implementation.
SEE ALSO
blowfish(3), procmail(1).
AUTHOR
StealthMonger <Stealt...@nym.alias.net>
2005 June 14
#if 0/*
exec gcc -g -o `basename $0 .c` $0 -lcrypto -lc;*/
#endif
/* Note: Because of the foregoing, an executable can be built
simply by issuing the command ``sh esubbf.c'' to the shell.
SYNOPSIS
esubbf <key> <subject>
DESCRIPTION
Write to stdout the 48 digit hexadecimal code of a number
derived according to the esubbf algorithm from the given <key>
and <subject>. Functions like mixmaster.ren1.c.t1_esub except
that it uses Blowfish instead of IDEA, avoiding patent issues.
The fields of the number can be pictured as follows:
______________________________________________
| | |
| random iv | encrypt(subject,key,iv) |
| 64 bits | 128 bits |
|_______________|_____________________________|
where "subject" and "key" refer to the 128-bit MD5 hashes of
the given <key> and <subject>, and encryption is computed by
BF_cfb64_encrypt(3).
SEE ALSO
esubbft
*/
#include <stdio.h>
#include <stdlib.h>
#include <openssl/md5.h>
#include <openssl/blowfish.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
void print8(unsigned char id[])
{
printf
("%02x%02x%02x%02x%02x%02x%02x%02x",
id[0], id[1], id[2], id[3], id[4], id[5], id[6], id[7]);
}
int main(int argc, char **argv)
{
BF_KEY ks;
int n=0, randfd;
char keyd[16], subd[16], tsvd[16], iv[8];
if ( argc != 3 ) return 1;
MD5(argv[1],strlen(argv[1]),keyd);
BF_set_key(&ks, 16, keyd);
MD5(argv[2],strlen(argv[2]),subd);
#if defined(__linux__)
randfd = open("/dev/urandom", O_RDONLY);
#elif defined (__OpenBSD__)
randfd = open("/dev/srandom", O_RDONLY);
#else
/* FIXME */
equivalent_for_your_architecture;
#endif
read(randfd, iv, 8);
print8(iv);
BF_cfb64_encrypt(subd, tsvd, 16, &ks, iv, &n, BF_ENCRYPT);
print8(tsvd);
print8(&tsvd[8]);
return 0;
}
#if 0/*
exec gcc -g -o `basename $0 .c` $0 -lcrypto -lc;*/
#endif
/* Note: Because of the foregoing, an executable can be built
simply by issuing the command ``sh esubbft.c'' to the shell.
SYNOPSIS
esubbft <key> <subject> <test>
DESCRIPTION
Return 0 if <test> might have been the result of running
"esubbf <key> <subject>", else 1. A succinct statement of the
functionality is that
esubbft <key> <subject> $(esubbf <key> <subject>) ; echo $?
gives 0.
SEE ALSO
esubbf
*/
#include <stdio.h>
#include <stdlib.h>
#include <openssl/md5.h>
#include <openssl/blowfish.h>
int scanbytes(const char* buf, unsigned char* bytes, const int count)
{
int i;
char s[]="0xxx" , *eptr;
for (i = 0; i < count; i++) {
s[2] = *(buf + 2*i) ;
s[3] = *(buf + 2*i + 1) ;
eptr = &s[0];
*(bytes + i) = (unsigned char) strtol(s, &eptr, 16);
if ( eptr == &s[0] ) return 1;
};
return 0;
}
int main(int argc, char **argv)
{
BF_KEY ks;
int n=0;
char keyd[16], subd[16], tsu[24], tsvd[16];
if ( argc != 4 || strlen(argv[3]) != 48 ) return 1;
if ( scanbytes(argv[3],tsu,24)) return 1;
MD5(argv[1],strlen(argv[1]),keyd);
BF_set_key(&ks, 16, keyd);
BF_cfb64_encrypt(&tsu[8], tsvd, 16, &ks, tsu, &n, BF_DECRYPT);
MD5(argv[2],strlen(argv[2]),subd);
return (memcmp(subd, tsvd, 16) == 0 ? 0 : 1);
}
#!/bin/sh
# SYNOPSIS
# esubbft-arthdr key sub
# DESCRIPTION
# Returns the result of calling esubbft key sub test, where
# test is a ^Subject: field found on standard input. Useful
# as a procmail test when fed the header of a candidate
# article.
esubbft $1 $2 $(sed -n 's/^Subject: //Ip')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>
iD8DBQFK9Md5DkU5rhlDCl4RAv04AJ4t7SaMjCWzM2Vio2gBnWlG6NZdzgCfde+d
CD5Ma9XmBKpzoVJVNI8BiDY=
=SRVT
-----END PGP SIGNATURE-----
Anon
identifying purposes after reading this:
http://www.mail-archive.com/mixmast...@lists.sourceforge.net/msg00079.html
Here is an explanation about esub I found in alt.privacy.anon-server:
Search alt.privacy.anon-server for Subject: 'Zax: question about hsub'
Message-Id: <fdb4ec0cafb243c6...@dizum.com>
>Not quite. eSub is quite complicated in comparison to hSub; it takes
>the plain text Subject and MD5 hashes it. It does the same with the
>Encrypt-Subject to produce a second MD5 hash. Next it IDEA encrypts
>the Subject hash using the Encrypt-Subject hash as the key and the 64
>bit IV as the IDEA initialisation vector. The resulting encrypted
>block is then prepended with the plain-text IV and the whole lot is hex
>encoded to create the eSub.
Anonymous
Anonymous
Pascal code for creating hsub:
//Generate 16 char initialization vector hex string
procedure TForm1.GenerateIV(Sender: TObject);
var RT : integer;
begin
Randomize;
GeneratedIV := '';
repeat begin
RT := Succ(Random(255));
GeneratedIV := GeneratedIV + Format('%.2x', [RT]);
end
until (RT >= 0) and (RT < 256) and (length(GeneratedIV) = 16);
GeneratedIV := lowercase(GeneratedIV);
end;
//Generate 32 char hashed of 'static subject + initialization vector'
(16 byte) hex string
//Use Delphi Cryptography Package at
http://www.cityinthesky.co.uk/cryptography.html
procedure TForm1.Sha1Routine(MySubject : string);
var x : integer;
Hash: TDCP_sha1;
HashDigest: array[0..31] of byte;
begin
ZeroMemory(@HashDigest, sizeof(HashDigest));
FillChar(HashDigest,Sizeof(HashDigest), $FF); // fill the digest
with $FF as the actual digest may not fill the entire digest
Hash:= TDCP_sha1.Create(Self);
Hash.Init;
Hash.UpdateStr(MySubject);
Hash.Final(HashDigest);
Hash.Free;
FinalSubject := '';
for x := Low(HashDigest) to High(HashDigest) do
FinalSubject := FinalSubject + Format('%x', [HashDigest[x]]);
SetLength(FinalSubject, 32);
FinalSubject := GeneratedIV + lowercase(FinalSubject);
end;