Zax: question about hsub
Nomen Nescio
because of the apparent necessity to lapse into extremely technical
jargon. At least, to the layman this appears so.
My question is, does the same subject text hash to the same hashed
value everytime? Esub produced a different hashed value every time.
With hsub, if I recieve a dozen messages from my nym with exactly
the same subject, will the hsub subject be also the same everytime?
Thanks!
Zax
Hash: SHA512
On Sat, 12 Sep 2009 05:16:50 +0200 (CEST), Nomen Nescio wrote in
Message-Id: <01eedfa15ae07e4a...@dizum.com>:
> My question is, does the same subject text hash to the same hashed
> value everytime? Esub produced a different hashed value every time.
> With hsub, if I recieve a dozen messages from my nym with exactly
> the same subject, will the hsub subject be also the same everytime?
No, the hsub will be different on each occasion. I'll try and explain
how it works....
The first 8 bytes (16 hex digits) of the hsub (and esub) are randomly
generated. For the sake of this example, lets say your random 8 bytes
are: aaaaaaaa. This is known as the IV.
The rest of the hsub is a SHA256 hash of the IV and subject joined
together, so if your subject was "test", your hsub would be:
'aaaaaaaa' + sha256('aaaaaaaa' + 'test'). This (in hex) is:
61616161616161617b536f1be88db02e16ae4abfc35fc39a6d633ed07cdc62f92a395706eda8d01f
We then trim that to 48 characters to make it look like an esub:
61616161616161617b536f1be88db02e16ae4abfc35fc39a
Make sense now? :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEAREKAAYFAkqrmFoACgkQlKZ6CY7Vd0N9dwCgjxem0CtVor8WG6gm5vuwxYgY
uwYAoIIh5CEA+Evmc6zdFkUvovoNKq6t
=qC42
-----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>
Zax
Hash: SHA512
On 12 Sep 2009 15:04:11 -0000, Bobby wrote in
Message-Id: <ZMBG1INZ4006...@reece.net.au>:
>>We then trim that to 48 characters to make it look like an esub:
>>61616161616161617b536f1be88db02e16ae4abfc35fc39a
>>
>>Make sense now? :-)
>>
> Wow! I actually understand that! Thanks :)
Great!
I should have explained previously how the client checks that hsub. It
knows the IV as it's the first 16 digits: 6161616161616161. Of course
everyone else knows it too. The secret part is the Subject.
If the client uses the IV from the hsub it wants to check, along with
the secret subject, the hsub it generates will be identical to the one
it's checking.
The client is not constrained to any specific length of hsub, it can
check any length that the server provides. We currently use 48 hex
digits to make the hsub output indestinguishable from an esub, but if
the server trims it's hsub to 64 digits instead, the client will still
happily check it without any modification. The maxium length is 80 hex
digits, (320 bits). That's the 64 bit IV + the whole 256 bit SHA256
hash.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEAREKAAYFAkqryoMACgkQlKZ6CY7Vd0OFvwCfZ2IjcDmGP3W6IQg6WpUxq976
bEAAn3es5xf3jNbuZ396NMljgtnKnAyS
=3wmX
Nomen Nescio
Zax <ad...@bananasplit.info> wrote:
>
>On Sat, 12 Sep 2009 05:16:50 +0200 (CEST), Nomen Nescio wrote in
>Message-Id: <01eedfa15ae07e4a...@dizum.com>:
>
>> My question is, does the same subject text hash to the same hashed
>> value everytime? Esub produced a different hashed value every time.
>> With hsub, if I recieve a dozen messages from my nym with exactly
>> the same subject, will the hsub subject be also the same everytime?
>
>No, the hsub will be different on each occasion. I'll try and explain
>how it works....
>
>The first 8 bytes (16 hex digits) of the hsub (and esub) are randomly
>generated. For the sake of this example, lets say your random 8 bytes
>are: aaaaaaaa. This is known as the IV.
>
>The rest of the hsub is a SHA256 hash of the IV and subject joined
>together, so if your subject was "test", your hsub would be:
>'aaaaaaaa' + sha256('aaaaaaaa' + 'test'). This (in hex) is:
>61616161616161617b536f1be88db02e16ae4abfc35fc39a6d633ed07cdc62f92a395706eda8d01f
>
>We then trim that to 48 characters to make it look like an esub:
>61616161616161617b536f1be88db02e16ae4abfc35fc39a
>
>Make sense now? :-)
Ok, I can see that now. You say esub uses the 8 random characters
also. I looked at the esub code and it looks to me like those
characters along with the hashed subject are encrypted into the
esub subject--not just tacked on as the first 8 bites of the
subject as it appears in a.a.m. Am I right about that?
Thanks for you explanations.
Neverwhere
news:slrnhanik3...@fleegle.mixmin.net...
Zax what tools will be needed to create the HSUB message? I'm currently using
QS and pgp 6.X.X and ESUB.
Nomen Nescio
>Hash: SHA512
>
>On Sat, 12 Sep 2009 05:16:50 +0200 (CEST), Nomen Nescio wrote in
>Message-Id: <01eedfa15ae07e4a...@dizum.com>:
>
>> My question is, does the same subject text hash to the same hashed
>> value everytime? Esub produced a different hashed value every time.
>> With hsub, if I recieve a dozen messages from my nym with exactly
>> the same subject, will the hsub subject be also the same everytime?
>
>No, the hsub will be different on each occasion. I'll try and explain
>how it works....
>
>The first 8 bytes (16 hex digits) of the hsub (and esub) are randomly
>generated. For the sake of this example, lets say your random 8 bytes
>are: aaaaaaaa. This is known as the IV.
>
>The rest of the hsub is a SHA256 hash of the IV and subject joined
>together, so if your subject was "test", your hsub would be:
>'aaaaaaaa' + sha256('aaaaaaaa' + 'test'). This (in hex) is:
>61616161616161617b536f1be88db02e16ae4abfc35fc39a6d633ed07cdc62f92a395706eda8d01f
>
>We then trim that to 48 characters to make it look like an esub:
>61616161616161617b536f1be88db02e16ae4abfc35fc39a
>
>Make sense now? :-)
Ok, I see.
So hsub foregoes the idea encryption. That IDEA hides the IV an
adds an extra layer of security. At least it looks like that to me.
Please, I'd like to know just how hsub compares securitywise to
esub. Is it the same security, more secure or less secure. If
different, about how much.
Zax
Hash: SHA512
On Sun, 13 Sep 2009 06:29:35 +0200 (CEST), Nomen Nescio wrote in
Message-Id: <fdb4ec0cafb243c6...@dizum.com>:
> Ok, I can see that now. You say esub uses the 8 random characters
> also. I looked at the esub code and it looks to me like those
> characters along with the hashed subject are encrypted into the
> esub subject--not just tacked on as the first 8 bites of the
> subject as it appears in a.a.m. Am I right about that?
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.
I don't know who came up with the eSub design but it seems incredibly
complicated to achieve the same result as the hSub. In terms of
strength, I can't see a lot of difference between them. In both
instances, linking messages without the key(s) would be extremely
difficult.
If you want the ultimate security, don't use eSub or hSub. Just try to
decrypt all the messages in a.a.m with your symmetric key. If you can't
decrypt them, they aren't yours. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEAREKAAYFAkquC28ACgkQlKZ6CY7Vd0P7DwCaAuGysqqseSC9fiax3QGTXPs2
VCAAoLty8TS/7MZaSl6qSoH4Lm/s/BR6
=YIKr
Anonymous
<snippage>
> So hsub foregoes the idea encryption. That IDEA hides the IV an
> adds an extra layer of security. At least it looks like that to me.
I'd say not really. The IV is "hidden" by esub because it has to be
to perform its function (initialization). Still, it wouldn't matter
if it were transmitted in the clear. The problem that needs solved
to read the message is cracking IDEA.
Hsub doesn't rely on a hidden IV either. The mathematical problem
that needs solved is reversing SHA. And as we all should know SHA
is a "one way" function.
So basically it comes down to which is more secure... SHA or IDEA.
I suppose you could debate the point, but it's been accepted for
some time now that IDEA is a weak cipher in modern days. There's
all sorts of "recommendations" out there regarding moving away from
it.
> Please, I'd like to know just how hsub compares securitywise to
> esub. Is it the same security, more secure or less secure. If
> different, about how much.
I'd say that for practical purposes they're very similar.
On a purely technical level I'd say hsub is *slightly* more secure
just by virtue of the fact that SHA is a tad more trusted than IDEA.
Nomen Nescio
A more likely scenario might be that a person might leak their
subject somehow...possibly testing in non-esub/hsub mode then not
changing the subject. Or possibly having a guessable subject. In
that case, it looks like esub has the edge because the password is
required as well...
George Orwell
> I'd say not really. The IV is "hidden" by esub because it has to be
> to perform its function (initialization). Still, it wouldn't matter
> if it were transmitted in the clear.
It is transmitted in the clear. It has to be to perform its function
(initialization). I saved this description from an earlier thread in this
newsgroup:
esub encrypted Subject header format:
48 Hex chars = 24 bytes
First 16 Hex chars (= 8 bytes) IV
Remaining 32 Hex chars (= 16 bytes) MD5(subject) IDEA encrypted with MD5(key)
Retrieve IV and encrypted string from Subject: header, decrypt with
MD5(key) and test against MD5(subject)
> The problem that needs solved to read the message is cracking IDEA.
That wouldn't solve anything unless you also know the secret subject to
look for. esub uses IDEA as a keyed hash function, mapping a static input
(subject, key) to a variety of outputs.
> So basically it comes down to which is more secure... SHA or IDEA.
I dare to say in this application even MD5 would qualify as "secure
enough".
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
.
Nomen Nescio
Zax, I'm surprised and disappointed you chose to reply anonymously
here. Don't you have confidence that the info you've given is
accurate? You can't put your name to it? It's evasive to post this
anonymously. Please give us your reply in a signed message. It was
an honest question. Your evaluation is fine with me--so long as I
know it's yours.
Zax
Hash: SHA512
On Mon, 14 Sep 2009 12:52:18 +0200 (CEST), Anonymous wrote in
Message-Id: <2009091410521...@www.ecn.org>:
> I'd say not really. The IV is "hidden" by esub because it has to be
> to perform its function (initialization). Still, it wouldn't matter
> if it were transmitted in the clear.
Actually the IV is transmitted in the clear. It's prepended to the hex
encoded output, same as with hSub.
> The problem that needs solved to read the message is cracking IDEA.
Yes, if you crack IDEA then you can link messages together because of
the static MD5 hashes created from Encrypt-Subject and Subject.
> Hsub doesn't rely on a hidden IV either. The mathematical problem
> that needs solved is reversing SHA. And as we all should know SHA
> is a "one way" function.
> So basically it comes down to which is more secure... SHA or IDEA.
> I suppose you could debate the point, but it's been accepted for
> some time now that IDEA is a weak cipher in modern days. There's
> all sorts of "recommendations" out there regarding moving away from
> it.
I think it comes down to which is best suited for the purpose of
de-linking messages. Encryption (in this case IDEA) is a two-way
function whilst SHA is one-way. In both eSub and hSub, the Subject is
*never* decrypted, it's just compared to another one generated using
known parameters. On this basis I think SHA is much better suited to
the task than IDEA.
> I'd say that for practical purposes they're very similar.
Me too. They both achieve the same goal and offer similar levels of
security. The goal of hSub was just to offer an alternative that isn't
dependent on IDEA. By fortune, it's also a lot simpler! :)
> On a purely technical level I'd say hsub is *slightly* more secure
> just by virtue of the fact that SHA is a tad more trusted than IDEA.
Yes, and as I said above, SHA being a one-way function is better suited
to purpose. In theory at least, there is no way back from a one-way
function. To date there is no evidence to support otherwise.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEAREKAAYFAkqx9HAACgkQlKZ6CY7Vd0OLsgCgtHBx2NrYlCeRYeyM0E35Bh8b
Xb4An1zDu2W5tVcXUaA4OPpfcYTghSiK
=THaS
George Orwell
> Don't you have confidence that the info you've given is
> accurate?
Anonymity precludes accuracy? Care to explain that, accurately?
> It's evasive to post this anonymously.
Bwahaha.
> Please give us your reply in a signed message. It was
> an honest question. Your evaluation is fine with me--so long as I
> know it's yours.
How about you do some evaluation yourself if you don't trust users on apas?
Nomen Nescio
Anonymous Remailer
Zax wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On Mon, 14 Sep 2009 12:52:18 +0200 (CEST), Anonymous wrote in
> Message-Id: <2009091410521...@www.ecn.org>:
>
> > I'd say not really. The IV is "hidden" by esub because it has to be
> > to perform its function (initialization). Still, it wouldn't matter
> > if it were transmitted in the clear.
> Actually the IV is transmitted in the clear. It's prepended to the hex
> encoded output, same as with hSub.
Thanks Zax, I wasn't really familiar with esub on any sort of tech
level, and assumed. ;)
I guess the point here is the fact that initialization/etc
characters can be transmitted in the clear without compromising
security. ;)
> > The problem that needs solved to read the message is cracking IDEA.
> Yes, if you crack IDEA then you can link messages together because of
> the static MD5 hashes created from Encrypt-Subject and Subject.
And, if you can link messages then esub is totally compromised. The
actual text of the Subject: line isn't really important (unless
you're foolish enough to use 'message for Dave Smith of 123 4th
St.' as your encrypt subject. <g>
> > Hsub doesn't rely on a hidden IV either. The mathematical problem
> > that needs solved is reversing SHA. And as we all should know SHA
> > is a "one way" function.
>
> > So basically it comes down to which is more secure... SHA or IDEA.
> > I suppose you could debate the point, but it's been accepted for
> > some time now that IDEA is a weak cipher in modern days. There's
> > all sorts of "recommendations" out there regarding moving away from
> > it.
> I think it comes down to which is best suited for the purpose of
> de-linking messages. Encryption (in this case IDEA) is a two-way
> function whilst SHA is one-way. In both eSub and hSub, the Subject is
> *never* decrypted, it's just compared to another one generated using
> known parameters. On this basis I think SHA is much better suited to
> the task than IDEA.
I agree 100% regarding suitability. And the hacker in me likes the
"elegance" of using SHA. But if we disregard the questionable
nature of MD5 and IDEA in some circles I see the problem of
cracking either as a brute force thing. an attacker is left hashing
or encrypting more or less random strings and looking for a collide.
I'm also left wondering how truncating hashes impacts security...??
> > I'd say that for practical purposes they're very similar.
> Me too. They both achieve the same goal and offer similar levels of
> security. The goal of hSub was just to offer an alternative that isn't
> dependent on IDEA. By fortune, it's also a lot simpler! :)
Agree again.
>
> > On a purely technical level I'd say hsub is *slightly* more secure
> > just by virtue of the fact that SHA is a tad more trusted than IDEA.
> Yes, and as I said above, SHA being a one-way function is better suited
> to purpose. In theory at least, there is no way back from a one-way
> function. To date there is no evidence to support otherwise.
In *theory* the attack vector is the same unless someone comes up
with a viable way of factoring large semi-primes. That's not to say
it couldn't happen tomorrow, so I concede this point also. The fact
that it might actually *be* possible to reverse IDEA gives SHA a
decided advantage.
Excellent work, by the way. :)
Anonymous
> with a viable way of factoring large semi-primes. That's not to say
> it couldn't happen tomorrow, so I concede this point also. The fact
> that it might actually *be* possible to reverse IDEA gives SHA a
> decided advantage.
Nice try, but in theory that's wrong...
Just for the record: nope, hashing and symmetric encryption algorithms
don't use prime number arithmetic or the discrete logarithm. This makes
them fast, but vulnerable to attacks other than NP=P.
Also, even with a hash function you'll have a unique solution, if you
don't have a lot of entropy in your plaintext.
Echeloff
>I'm also left wondering how truncating hashes impacts security...??
As you offer less information, for an attacker the risk of getting
false positive correlations increases, which isn't bad.
>Excellent work, by the way. :)
I agree.
Echeloff