[Info-vax] VSI has released 9.2-1

[Arne Vajhøj]

On 7/5/2023 7:32 PM, Dave Froble wrote:
> On 7/5/2023 3:37 PM, Arne Vajhøj wrote:
>> On 7/5/2023 9:05 AM, Dave Froble wrote:
>>> On 7/4/2023 9:25 PM, Arne Vajhøj wrote:
>>>> On 6/19/2023 9:43 PM, Dave Froble wrote:
>>>>> People who count for encryption to provide protection don't really 
>>>>> care all
>>>>> that much.  Do enough to check the appropriate box, then not their 
>>>>> problem.
>>>>>
>>>>> People who really care about security of course may use SSL, but 
>>>>> then what
>>>>> happens when the encryption is broken?  The user's data is 
>>>>> available to the
>>>>> hackers.  But what if the app developers insured that the data, if 
>>>>> encryption
>>>>> is defeated, doesn't really mean anything to the hackers.  Some 
>>>>> custom stuff
>>>>> in addition to SSL and such.  Yeah, even then, some hacker might 
>>>>> figure out
>>>>> the data.  But isn't it better to make it as tough for the hacker 
>>>>> as one can?
>>>>>
>>>>> Now I'll hear from some "you got to use standards".  I'd ask 
>>>>> "why?"  The
>>>>> problem with standards is, everybody knows them.
>>>>
>>>> There are two benefits from going standard.
>>>>
>>>> Interoperability. If the communication is based on standards, then
>>>> software from different vendors can communicate. SSL (TLS 1.2 or 1.3
>>>> of course!) is widely supported standard so C programs on VMS,
>>>> Java programs on Linux and VB.NET programs on Windows can communicate
>>>> without problems due to the standard.
>>>>
>>>> Security. The public known standard protocols and algorithms are being
>>>> reviewed by thousands of mathematicians all over the world. A home 
>>>> grown
>>>> protocol and algorithm will be reviewed by a few software engineers
>>>> which may or may not have math/cryptography knowledge. The first will
>>>> simply result in a better solution.
>>>>
>>>> Good cryptography does not depend on protocols or algorithms
>>>> being unknown. It is possible to constructs stuff that are secure
>>>> even with known protocols/algorithms. And protocols/algorithms
>>>> that are not secure if known are very bad. They will eventually leak.
>>>
>>> You sort of missed the point of my post.
>>
>> I miss a lot.
>>
>> But I read it as that you suggested not using standard
>> protocols/algorithms but something unique/homemade.
>>
>> Was that not the case?
> 
> No!
> 
> I use such as SSL and other standards.
> 
> But then, it's not enough to say "hey, we use standards", and assume all 
> will be well.  Perhaps going beyond such and further trying to make your 
> data useless to those who should not have it.

So you are suggesting a double encryption scheme. An application
specific encryption of the payload being transported encrypted by SSL.

If that application specific encryption use the same algorithms as
SSL, then it will not provide any benefits.

But using different algorithms is protecting you against a
future fatal flaw in one of the algorithm sets.

I will consider the risk of a fatal flaw in AES or RSA/ECC
to be found very small.

But if the application is controlling launch of ICBM's then it
may be warranted to add the extra layer of security.

Arne