Re: AES MAC security question

From: Andrew Swallow (am.swallow_at_btopenworld.com)
Date: 07/04/05 

Date: Mon, 4 Jul 2005 00:00:35 +0000 (UTC)

Rein Anders Apeland wrote:
> On Sun, 2005-07-03 at 10:25 +0000, Joseph Ashwood wrote:
>
> <snip>
>
>>Because the goal is to verify the transmitter, not to stop observation of
>>the communication the encrypted stream is only a "because our clients want
>>it" decision. There is the additional penalty that you will have to have
>>some form of identification outside the packet so the receiver can perform a
>>bulk filter on things to ignore, so you are actually increasing either the
>>transmission size by a small amount (transmitter ID size) or increasing the
>>compute overhead for the receiver by a lot. This overcomes the hidden
>>transmitter ID problem because it is immediately revealed, so I really can't
>>see any cryptographic advantage to performing the encryption, what I do see
>>is that anyone who looks at information coming from the keeloq system which
>>is completely encrypted and the unencrypted version would probably assume
>>the keeloq system was more secure because we're trained that way giving a
>>particularly compelling marketting advantage to the encryption.
>> Joe
>
>
>
> IMHO I do not need identification outside the encrypted packet.
> The receiver just decrypts all received packets with the key
> that is shared between the one car and all its associated fobs, and
> then checks the MAC of the decrypted packet. If the MAC is not valid,
> ignore the packet. Then, of course, wait e.g. 1 second before accepting
> new packets. Yes, this requires another key stored in the fob, and more
> computing, but the packet size is the same and the ID, counter and cmd
> is hidden. Doesn't this give at least _some_ advantage other than just
> "it _looks_ more secure to the non-expert customer", given that I can
> afford the key storage and additional computation in the fob? And
> wouldn't that give at least _some_ security advantage over the
> shared-secret-solution? In this case, an attacker cannot just try
> guessing the MAC. Even getting the ID right would be a major problem,
> right?
>
Hiding the ID has advantages but you now need a IV field to initialise
the crypto, possibly the count, which will have to be sent in plain text.

In a busy car park several people may be unlocking their cars at the
same time, so 1 packet a second may be too slow.

Andrew Swallow

Relevant Pages

  • Re: Van Jacobsons net channels and real-time
    ... packages with real-time latencies. ... Finding the end point in the receive interrupt and send of the packet to ... through soft irq which might be busy working on IP packages. ... Each end receiver provides his own receive resources. ...
    (Linux-Kernel)
  • Re: AES MAC security question
    ... > compute overhead for the receiver by a lot. ... > particularly compelling marketting advantage to the encryption. ... IMHO I do not need identification outside the encrypted packet. ... then checks the MAC of the decrypted packet. ...
    (sci.crypt)
  • Re: Converting C++ header file to Delphi4 pas unit
    ... > component for long lines and situations where the transmitter and receiver ... If you choose the right PCI card, ... > can probably see that the issue of baudrate and packet size is critical. ... > not you can only get the approximate baud rate you are after. ...
    (comp.lang.pascal.delphi.misc)
  • Re: CSocketFiles / CArchive vs Raw Buffer Manipulation
    ... such as network packet transmission. ... UDP within a LAN often gives the effective illusion that it is reliable. ... fail without warning of any sort to either the sender or the receiver. ...
    (microsoft.public.vc.mfc)
  • Re: AES MAC security question
    ... >> That depends on what sort of receiver you are using. ... > - Each and every transmitter has its unique key. ... Just monitor the transmitted packet, and send a bunch of ... Then when the owner turns up with their keyfob, ...
    (sci.crypt)
Loading