Hi Netzblocker,
I regret that we must simply agree to differ on this. I have made it my #1
priority this year to prevent encryption from coming to Amateur radio in the
U.S. and wherever else possible. This for several reasons:
* Amateur radio isn't for private communications. Encryption makes it much too
easy to keep a communication private.
* Encrypted frequencies are no longer shared frequencies. Hams who don't know
the key can neither monitor nor participate.
* Encryption defeats self-policing in the Amateur service.
* Encryption facilitates the use of frequencies for purposes we don't desire in
the Amateur spectrum.
* Amateur Radio must be _harmless_ in order to continue to be supported by
governments. With encryption, there's no longer any expectation that it's
harmless.
Since we are making a tool (Codec2) that is very easy to use for encryption,
it's our responsibility to keep it from harming the Amateur service. I have no
objection to your making use of it with encryption in some other radio service.
Thanks
Bruce
Netzblockierer <netzblockie...@privatdemail.net> wrote:
>Am 15.03.2013 06:11, schrieb Barry White:
>> Netzb ? I suspect you missed a critical part of the discussion.
>> It has never been about normal AR communications.
>>
>> It was about when the government authorities controlling an emergency
>
>> situation require us to transmit information such as lists of dead
>> victims or similar sensitive information and request encryption.
>Well, we both know that in this case, there are already existing
>systems
>that are ready for use.
>For example, the ''Harpoon'' - System, developed for the NATO by
>AEG/Telefunken, which is still today a leading Hardware Platform for
>secure radio communications without any other infrastructure:
>
>Frequencies: 2 kHz - 30 kHz
>in 0,001 kHz - steps
>
>As you obviously know, these frequencies allow transcontinental
>connectivity (~ 6000km) without satellites due to Inonosperic
>reflection.
>
>These devices have been packed in suitcases, weighting about 8kg
>(including batteries) and allow autonomous transmission/recieving and
>encryption/decryption of messages as well as forwarding them...
>
>
>After my knowledge, Australia owns several of them due to their ANZUS -
>membership. So it seems very unlikely that they will use infrastructure
>owned by civilians (which applies to most hams! - Please correct me if
>I'm wrong!).
>In the case, they would need an encryption, they would do this via
>embedded hardware. In such cases, they apply the need-to-know -
>principle, and may earlier confiscate your entire ham - equipment
>rather
>than involving you, except you are in some sort of organization that
>may
>be given order to do so (e.g. police, fire-brigade, civil-defense,
>etc.)...
>
>
>Nevertheless, I don't see there any sense in implementing a technology
>while prohibiting the use of it for the general public.
>So if hams are not allowed to use encryption, and do not want to
>disobey
>their regulative authorities in this case, why should they then take
>care of this problem?
>
>For me, it seems ridiculous to do so if it is not intended to be used
>(with or without consent of authorities) in regular use.
>The fact, that encryption is banned for AR applications still feeds my
>theory that truly secure communication is not in the interest of
>governments, but I think this is going ''too much tinfoil hat'' for
>this
>mailing-list.
>
>
>
>Actually, I'm working on a solution for end-to-end encrypted telephony
>and data transmissions using Codec2 and other open-source software. In
>the end, it could operate paralell streams of voice and data, offering
>to split the bandwith 50:50 or offer the entire bandwith to one
>service.
>Seems quite hard, but ony Codec2 seems capable to keep bandwith low
>enough for usage via public phone booths (most acoustic couples only
>offer 2400 bit/s due to the microphone's - and speaker's quality, which
>is quite poor... Other codecs such as AMBE or MELP are patented and
>thereof are excluded for use. If someone is really interested in
>implementing them, he'll be able to do so on his own...
>
>The last one who developed such a hardware that allows encrypted
>telephony (and was planed to enable encrypted data transmissions, too)
>was murdered in 1998 by being hung with a steel cable, then cooled down
>in a fridge and hanged again in a park in the middle of Berlin.
>His name was ''TRON'' See https://en.wikipedia.org/wiki/Tron_(hacker)
>for details...
>
>
>Yours sincerely,
>Netzblockierer
>
>
>>
>> Barry VK2AAB
>> Wicen Liason, Hornsby Kuringai Emergency Management Committee
>>
>> Netzblockierer wrote:
>>> I'm quite woundering why Encryption has been topic this late.
>>>
>>> It is possible to use an encryption. The most simple way would be a
>>> Diffie-Hellman Key-Exchange (even over-the-Air) and then using
>AES-256
>>> bitwise; making a buffer of 256 bits before transmission
>necessary...
>>>
>>> But even if the entire encrypion would be specified and
>open-licensed
>>> alike Codec2, I do not believe that any regulatory authority, like
>the
>>> FCC, allows it...
>>>
>>> In Germany, the authorities forbid the usage of encryption on
>CB-Band;
>>> even when used on data transmission channels, saying that it cannot
>be
>>> identified by them or other users as intentional broadcast and may
>>> declare it as RF-noise and excessive disturbing of other frequency -
>
>>> users...
>>>
>>> It seems likewise the GSM [pseudo] 'encryption' A8/A5/A3, that such
>>> technology that truly provides security (GSM never has!) violates
>the
>>> ''Wassenaar Threaty'', by declaring, that it could be used by
>'bad/wrong
>>> guys', too.
>>>
>>> In detail, when operating a CB-Gateway, it may be called an
>>> ''[Mobile/Wireless] Telephony Service Provider'' and automatically
>>> becomes subject to ''Lawful Interception'', that enforces the
>operator
>>> to decrypt all traffic and refuse the transmission of traffic that
>>> cannot be decrypted.
>>>
>>> However, implementing an encryption seems quite useful.
>>>
>>>
>>> Am 12.03.2013 21:44, schrieb Bruce Perens:
>>>> Hi Doug,
>>>>
>>>> Yes, I'd heard of this before. Our mission, this time, it
>authenticate
>>>> without obscuring the message content. So, chaffing probably won't
>be
>>>> part of the picture.
>>>>
>>>> Thanks
>>>>
>>>> Bruce
>>>>
>>>>
>>>> On 03/12/2013 12:56 PM, Douglas Quagliana wrote:
>>>>> Hi Bruce,
>>>>>
>>>>> Just to muddy the waters... there is a way to preserve
>confidentiality
>>>>> without
>>>>> using any encryption, but I don't know if this satisfies things
>like
>>>>> HIPPA. See
>>>>>
>>>>> http://people.csail.mit.edu/rivest/Chaffing.txt
>>>>>
>>>>> >From the above article:
>>>>>
>>>>>> In summary, we have introduced a new technique for
>confidentiality,
>>>>>> called ``chaffing and winnowing''. This technique can provide
>>>>>> excellent confidentiality of message contents without involving
>>>>>> encryption or steganography.
>>>>> Douglas
>>>>>
>>>>>
>>>>>
>------------------------------------------------------------------------------
>
>>>>>
>>>>> Everyone hates slow websites. So do we.
>>>>> Make your web apps faster with AppDynamics
>>>>> Download AppDynamics Lite for free today:
>>>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>>>> _______________________________________________
>>>>> Freetel-codec2 mailing list
>>>>> Freetel-codec2@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>>>
>>>>
>>>>
>------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>>>
>>>>
>>>> _______________________________________________
>>>> Freetel-codec2 mailing list
>>>> Freetel-codec2@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>>>
>>>>
>>>>
>>>> ---
>>>> avast! Antivirus: Eingehende Nachricht sauber.
>>>> Virus-Datenbank (VPS): 130313-0, 13.03.2013
>>>> Getestet um: 13.03.2013 18:05:45
>>>> avast! - copyright (c) 1988-2013 AVAST Software.
>>>> http://www.avast.com
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>------------------------------------------------------------------------
>>>
>>>
>------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>>
>>>
>>>
>------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Freetel-codec2 mailing list
>>> Freetel-codec2@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>
>------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> Freetel-codec2 mailing list
>> Freetel-codec2@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>
>>
>> ---
>> avast! Antivirus: Eingehende Nachricht sauber.
>> Virus-Datenbank (VPS): 130315-0, 15.03.2013
>> Getestet um: 15.03.2013 19:38:59
>> avast! - copyright (c) 1988-2013 AVAST Software.
>> http://www.avast.com
>>
>>
>>
>
>
>------------------------------------------------------------------------------
>Everyone hates slow websites. So do we.
>Make your web apps faster with AppDynamics
>Download AppDynamics Lite for free today:
>http://p.sf.net/sfu/appdyn_d2d_mar
>_______________________________________________
>Freetel-codec2 mailing list
>Freetel-codec2@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/freetel-codec2
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2