Prev: What could WYLBNIMGTHAD possibly mean?
Next: Converting byte[] to ASN1 stream fails - reads until byte 22
From: Yehudidedum on 27 Jul 2010 14:41
On Jul 27, 5:59 pm, jbriggs444 <jbriggs...(a)gmail.com> wrote:
> On Jul 27, 12:03 pm, Yehudidedum <pete.mce...(a)metastate.co.uk> wrote:
>
> > I do not know much about cryptography so any help is
> > very much appreciated.
>
> > If I wanted to broadcast a series of message of 4 bytes
> > that was incrementing each second.
> > '0x4C4EF473', '0x4C4EF474' etc.
> > I have no need what so ever to hide the contents
> > of the message – I only want to be able to tell who
> > sent it.
>
> Eh?
>
> That's a pretty tight syntax constraint on your message
> space.  You can control the starting number and
> the ending number and nothing else.  All the remaining
> data is uniquely determined by the 4 byte starting
> value -- each 4 byte value is one higher than the
> previous.
>
> There are only 2^64 - 2^32 + 1 such messages available
> and the +1 is only usable if you count the empty
> message.
>
> How are you planning to fit 192 bytes of signature into
> a message that contains less than 64 bits of information?
>
> > The problem is that I only have perhaps 192 bits of
> > possible bandwidth to carry the entire data, both
> > message and signature.
>
> How did you arive at this figure?  And having arrived
> at it, why would the coding scheme that supposedly
> imposes the 192 bit constraint be relevant?

Sorry, it was a stupid mistake, I had meant to state
that I had 384 or so bits. Ie, just enough for the
signature.

I was really concerned that if I was producing
very many messages that all had the the top bits
always recovered to the same value ,ie, the marker
inside the decoded public result. That this was of use to
some attacker. Either to spoof or crack the private key.

Many thanks,
Yehudi
From: Yehudidedum on 27 Jul 2010 15:06
On Jul 27, 5:42 pm, Ilmari Karonen <usen...(a)vyznev.invalid> wrote:
> Is this for a time synchronization protocol or something?  That's the
> only reason I can think of for wanting to broadcast a signed stream of
> linearly increasing numbers.
It is not for a signed time message - but well done for spotting
my use of the epoch time.
The application is actually to protect things like printed tickets.
So they could be validated, not spoofed, and at worst copied.
The available characters for any type of signature is very limited
hence the restriction on size.

> Tom's suggestion of splitting the signature over multiple messages
> ought to work, with the obvious limitation of not allowing immediate
> verification.  However, have you considered simply trading off message
> frequency for size?  Do you really _need_ to send messages every
> second, or would, say, 10 second intervals be feasible?
Alas, it is for printed material and so splitting will not
work - great idea though.

Again, thanks,
Yehudi
From: jbriggs444 on 28 Jul 2010 08:17
On Jul 27, 3:06 pm, Yehudidedum <pete.mce...(a)metastate.co.uk> wrote:
> On Jul 27, 5:42 pm, Ilmari Karonen <usen...(a)vyznev.invalid> wrote:> Is this for a time synchronization protocol or something?  That's the
> > only reason I can think of for wanting to broadcast a signed stream of
> > linearly increasing numbers.
>
> It is not for a signed time message - but well done for spotting
> my use of the epoch time.
> The application is actually to protect things like printed tickets.
> So they could be validated, not spoofed, and at worst copied.
> The available characters for any type of signature is very limited
> hence the restriction on size.

So your new problem description says that you have
an overtly printed 32 bit sequence number and 384
bits of additional data which may or may not be
concealed.

Instead of picking up this information as a series of 32 bit
sequence numbers being broadcast over the airwaves
without seeing the 384 bits you are now picking up this
information as the ticket-taker at a venue and are able to
scan in all 416 bits.

Instead of trying to determine the origin of a sequence
number stream, you are now attempting to verify the
origin of a particular set of 416 bits taken in isolation.

Possibly you are so close to the problem that you are
taking the details for granted and not communicating
them clearly.
First  |  Prev  | 
Pages: 1 2
Prev: What could WYLBNIMGTHAD possibly mean?
Next: Converting byte[] to ASN1 stream fails - reads until byte 22