Discussion:
[Freetel-codec2] Frame Ideas for 4FSK
Steve
2016-08-27 16:18:29 UTC
Permalink
I was playing with my calculator again on the patio, and I was thinking of
a method to modulate a 4FSK signal. Given the various vocoder options, it
seems that the best would be one with FEC, and fit in 64 bits, which puts
the 1300 bps as the top codec2 candidate.

Since there is a 25 Hz frame rate, applying that to a 1200 Baud modem, you
get 96 bits (or 48 symbols of a 4FSK modem).

#define RATE 25.0f
#define PERIOD (1.0f / RATE)
#define BAUD 1200
#define FREQSEPARATION BAUD
#define SAMPLERATE 48000
#define CYCLE SAMPLERATE / BAUD
#define SYMBOLS (int)((float)BAUD * PERIOD)

Alas, 64 bits leaves 32 bits left over. What to do with them??

52 Bits 12 Bits 32 Bits
+------------------+---------+------------------------------------------+
| CODEC2 Mode 1300 | FEC | TBD |
+------------------+---------+------------------------------------------+
| VOICE FRAME |
+-----------------------------------------------------------------------+
96 Bits per Frame
40 ms

struct voiceFrame {
unsigned int vocoder : 52;
unsigned int fec : 12;
unsigned int tbd : 32;
};


It makes for a nice number of data bytes though...


8 Bits 8 Bits 8 Bits 8 Bits
+--------+--------+--------+------------------------ --- --+---------+
| BYTE 1 | BYTE 2 | BYTE 3 | | BYTE 12 |
12 ASCII or 6 Unicode
+--------+--------+--------+------------------------ --- --+---------+
| DATA FRAME |
+--------------------------------------------------- --- ------------+
96 Bits per Frame
40 ms

struct dataFrame {
union data {
unsigned char bytes[12];
unsigned int unicode[6];
};
};


So, putting together a superframe of some fraction of a second (.4 seconds
sounds good), we can transmit 9 vocoder frames.

The first frame would be the header, and you can fill-in the audio with the
last vocoder frame sent in the previous superframe, or you can put in some
white noise if this is the starting frame.

That gives you 864 data bits or 108 bytes. That's a lot of bytes every half
second or so. You could do all the fancy routing even with IPV4 :-)


96 Bits 96 BITS 96 BITS 96 BITS 96 BITS
+---------------+---------+---------+---------+-- --- --+---------+
| HEADER FRAME | FRAME 1 | FRAME 2 | FRAME 3 | | FRAME 9 |
+------+--------+---------+---------+---------+-- --- --+---------+
| SYNC | PDW | VOICE/DATA FRAME (360 ms) |
108 ASCII or 54 Unicode
+------+--------+-------------------------------- --- ------------+
| SUPERFRAME |
+------------------------------------------------ --- ------------+
960 Bits per Superframe
400 ms

struct superFrame {
unsigned int sync : 32;
unsigned int vod : 1;
unsigned int pdw : 63;
union frame {
struct voiceFrame voicePackets[9];
struct dataFrame dataPackets[9];
};
};


That provides a second problem. What to do with an extra 63 bits? Not quite
enough for 6 bit amateur callsign routing, but I'm sure there is a lot of
ideas out there.


8 Bits 8 Bits 8 Bits 8 Bits 1 Bit 63 Bits
+---------+---------+---------+---------+-----+-------------
------------------------------+
| 0x1A | 0xCF | 0xFC | 0x1D | VOD | TBD
|
+---------+---------+---------+---------+-----+-------------
------------------------------+
| SYNC WORD (32 Bits) | PACKET DEFINITION WORD
(64 Bits) |
+---------------------------------------+-------------------
------------------------------+
96 Bits
40 ms

Notes:

VOD = Voice or Data Bit
TBD = To Be Determined

73/steve
Dean Hall
2016-08-27 20:52:10 UTC
Permalink
I read an academic paper in the past 5 years (can't cite it off the top of my head, though) that performed cryptographic authentication of streaming data in the following manner.

Streaming Data :
[
[Payload 0][SigByte 0]
[Payload 1][SigByte 1]
[Payload 2][SigByte 2]
...
[Payload N][SigByte N]
]

Where
256 < Sizeof(Payload) < 1024
and
SigByte N := LeastSignificantByte( CryptographicSignature( Payload N ))

Each transmission frame (or maybe a superframe) has one byte of signature. By itself, one byte of authentication is not very trustworthy. But as N becomes large, the trust of the streaming signature becomes strong. In other words, if you do this over 64 payloads or more, it's good enough for amateur purposes.

!!Dean
KC4KSU
That provides a second problem. What to do with an extra 63 bits? Not quite enough for 6 bit amateur callsign routing, but I'm sure there is a lot of ideas out there.
73/steve
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
e***@vk5kbb.com
2016-08-27 23:51:12 UTC
Permalink
Dean,
My apologies if I have come in late to this discussion but I too have
been
looking at data payloads and cryptographic techniques and I am wondering
why
the AES engine in the STM32 device is not applied , the only limitation
is
that it works on 128 or 256 bit packets.
However form there standard cryptographic techniques can be applied for
enhancing the security and integrity of the data stream.

Regards
Eric
Post by Dean Hall
I read an academic paper in the past 5 years (can't cite it off the top of my head, though) that performed cryptographic authentication of streaming data in the following manner.
[
[Payload 0][SigByte 0]
[Payload 1][SigByte 1]
[Payload 2][SigByte 2]
...
[Payload N][SigByte N]
]
Where
256 < Sizeof(Payload) < 1024
and
SigByte N := LeastSignificantByte( CryptographicSignature( Payload N ))
Each transmission frame (or maybe a superframe) has one byte of signature. By itself, one byte of authentication is not very trustworthy. But as N becomes large, the trust of the streaming signature becomes strong. In other words, if you do this over 64 payloads or more, it's good enough for amateur purposes.
!!Dean
KC4KSU
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]
Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Steve
2016-08-28 00:28:09 UTC
Permalink
Eric, I've thought about authentication, but I always come up empty
handed, as an open source program has no secrets, so you can't program
a per-device identification.

I think someone out there probably makes a chip that outputs a global
id (lots of bits) and would be different for every board produced.
Certainly enough bits to mechanize some kind of AES authentication
scheme.

I bet they sell for $1 in 10,000 quantity! The bast..... :-)

------------------------------------------------------------------------------
e***@vk5kbb.com
2016-08-28 01:29:25 UTC
Permalink
Well all current key public key distribution systems available
compromise the AES encryption system from a mathematical brute force
stand point.
Though I was thinking more along the lines of using a private key system
and implementing it in a simpler form.

Its all quite academic I think however as isn't any form of encryption
on the Amateur bands a violation of the license agreement?

Regards

Eric
Post by Steve
Eric, I've thought about authentication, but I always come up empty
handed, as an open source program has no secrets, so you can't program
a per-device identification.
I think someone out there probably makes a chip that outputs a global
id (lots of bits) and would be different for every board produced.
Certainly enough bits to mechanize some kind of AES authentication
scheme.
I bet they sell for $1 in 10,000 quantity! The bast..... :-)
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]
Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Steve
2016-08-28 01:37:34 UTC
Permalink
...isn't any form of encryption on the Amateur bands a violation of the
license agreement?

Authentication is approved, but most countries restrict the communication
itself from being encrypted.

Karn wrote about it way back in 87:
https://www.tapr.org/pdf/CNC1987-AnotherLookAtAuthentication-KA9Q.pdf
Dean Hall
2016-08-28 01:18:54 UTC
Permalink
Hi Eric,

Yes, AES could be used for security and integrity.
However, security and integrity are separate goals from authentication.

If I emit a digital voice stream and append a digital signature,
the recipients can have reasonable trust that my stream was created
by someone in possession of my private key. Ideally, that's only me.

To answer your question about why AES should not be used for authentication...
is a little detailed.

AES could be used to encipher a hash of the data to create a signature.
But since AES is a symmetric algorithm, you'd have to give away your key
to whomever wishes to authenticate the signature. And once your key is
given away, anyone could imitate you. So that's no good.

Asymmetric algorithms (and keys) must be used so that you can create
a signature using your private key and others my authenticate the signature
with your public key.

!!Dean
KC4KSU
Dean,
My apologies if I have come in late to this discussion but I too have been
looking at data payloads and cryptographic techniques and I am wondering why
the AES engine in the STM32 device is not applied , the only limitation is
that it works on 128 or 256 bit packets.
However form there standard cryptographic techniques can be applied for
enhancing the security and integrity of the data stream.
Regards
Eric
Post by Dean Hall
I read an academic paper in the past 5 years (can't cite it off the top of my head, though) that performed cryptographic authentication of streaming data in the following manner.
[
[Payload 0][SigByte 0]
[Payload 1][SigByte 1]
[Payload 2][SigByte 2]
...
[Payload N][SigByte N]
]
Where
256 < Sizeof(Payload) < 1024
and
SigByte N := LeastSignificantByte( CryptographicSignature( Payload N ))
Each transmission frame (or maybe a superframe) has one byte of signature. By itself, one byte of authentication is not very trustworthy. But as N becomes large, the trust of the streaming signature becomes strong. In other words, if you do this over 64 payloads or more, it's good enough for amateur purposes.
!!Dean
KC4KSU
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
Steve
2016-08-28 01:29:03 UTC
Permalink
Dean, the AES STM32 library does have three HMAC (one-way) hash
algorithms built-in. Four if you count MD5, but no one counts that
anymore :-)

73/steve

------------------------------------------------------------------------------
Dean Hall
2016-08-28 01:42:01 UTC
Permalink
AES is a symmetric (1 key) algorithm, so
the recipient must use the original key to verify the HMAC.

If you use AES to make a signature, you have to get the original key
to your recipient and trust (s)he doesn't share it.
So you can't really use symmetric algorithms to authenticate
your messages if your target is the general public
because you'd have to share your key with everyone
(and a bad actor could turn around and imitate you).

This is why we use asymmetric algorithms for digital signatures.

!!Dean
KC4KSU
Post by Steve
Dean, the AES STM32 library does have three HMAC (one-way) hash
algorithms built-in. Four if you count MD5, but no one counts that
anymore :-)
73/steve
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
Steve
2016-08-28 01:57:00 UTC
Permalink
I guess the problem with a public key, is you would have to 1) pick a
session key, and 2) send that key. But since we (USA anyway) can't
encrypt information over amateur radio (the session key), you can't
use that for authenticating users either.

Which is fine I guess, the people that need authentication should
probably get a county radio and a badge anyway...

------------------------------------------------------------------------------
e***@vk5kbb.com
2016-08-28 01:59:01 UTC
Permalink
Yes my mistake and why I initially apologised for coming in to the
conversation late.

I foolishly thought the discussion was along the same plane of thought I
had about applying encryption to the data stream.

Oh well sorry for wasting your time.

Regards

Eric
Post by Dean Hall
AES is a symmetric (1 key) algorithm, so
the recipient must use the original key to verify the HMAC.
If you use AES to make a signature, you have to get the original key
to your recipient and trust (s)he doesn't share it.
So you can't really use symmetric algorithms to authenticate
your messages if your target is the general public
because you'd have to share your key with everyone
(and a bad actor could turn around and imitate you).
This is why we use asymmetric algorithms for digital signatures.
!!Dean
KC4KSU
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]
Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Dean Hall
2016-08-28 03:15:43 UTC
Permalink
Other idea for spare bits:

Yes you could do routing. It would have to be state-ful; the routers would need to remember. At the beginning of your transmit stream, a header data structure identifies the intended recipient and establishes a stream ID. All the packets that follow claim to be a part of that stream ID and get routed accordingly. It's a fragile arrangement, but it's a possibility.

To flip the coin... if routing is desired, I think I'd rather start with a packet routing system and add digital voice at the application layer.

!!Dean
KC4KSU
That provides a second problem. What to do with an extra 63 bits? Not quite enough for 6 bit amateur callsign routing, but I'm sure there is a lot of ideas out there.
------------------------------------------------------------------------------
Loading...