[Botan-devel] DSA signature verification always returns false

Z. S. O. tiredashell at gmail.com
Wed Apr 22 12:25:45 EDT 2009

My general issue is that I want to send data from A to B over a network. So,
for example, to send a file you could break it up into 1KB chunks and send
each piece with a DSA signature. This would prevent a man-in-the-middle from
injecting his own random data to corrupt the file transfer, but it wouldn't
stop him from simply repeating packets (so I get several copies of the same
1KB chunk).

My current solution for how to send data securely is as follows:

session ID + packet number + data + DSA signature

In other words, every packet must include the session ID that the requester
randomly-generated, an incrementing packet number, the data itself, and
finally a DSA signature of everything. The recipient first checks that the
session ID is the same throughout the file transfer, then makes sure the
packet number is exactly one higher than the previous packet, then verifies
the DSA signature, then saves the data.

Essentially, the session ID and packet number guard against two different
kinds of replay attacks. The first guards against someone replaying a packet
that was sent in an entirely different transfer, and the second guards
against someone replaying a packet within the current transfer.

If there's any flaw in my reasoning (or an easier way to accomplish this)
please let me know.

On Mon, Apr 20, 2009 at 5:17 PM, Jack Lloyd <lloyd at randombit.net> wrote:

> On Fri, Apr 17, 2009 at 11:22:02PM -0400, Z. S. O. wrote:
> > While we're still on the topic, I was wondering: does Botan have a
> standard
> > way to generate pseudo-random session tokens for data that I digitally
> sign?
> For just choosing uniform random values, AutoSeeded_RNG is probably
> the best general choice in botan.
> > >From what I understand, the only way to avoid a replay attack is to use
> > sign(data+token) instead of sign(data). I could always generate my own
> > random token, but I don't like to invent my own standards if I can help
> it.
> Could you explain more about what you're trying to do / what problems
> you are facing? In general I don't think this is going to solve the
> replay problem, unless you keep track of each token that you have
> previously seen.
> > Besides, I'm not sure how big the token has to be for it to be considered
> > "secure."
> For something like this, I would guess you just want to make sure it
> doesn't repeat. If you take a uniform random source of N bit numbers,
> and generate 2^(N/2) of them, statistically you have about a 50%
> chance of one repeating. (This is called the 'birthday paradox', there
> are many articles explaining it online). So if you expected each key
> to sign no more than, say, 2^64 messages (which seems pretty
> reasonable in most cases), a 128 bit token would be sufficiently large
> that you could expect that the same token would never be choosen more
> than once for use with any one key (as long as you always used a good
> -Jack
> _______________________________________________
> botan-devel mailing list
> botan-devel at randombit.net
> http://lists.randombit.net/mailman/listinfo/botan-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/botan-devel/attachments/20090422/6ce1fc1f/attachment.html>

More information about the botan-devel mailing list