[Info-vax] VSI has released 9.2-1

[Dave Froble]

On 7/5/2023 7:57 PM, Arne Vajhøj wrote:
> 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
>
>
>

Ok, an example:

Back when we were storing customer credit card information,  we broke the number 
into 2 parts, and stored each part on two different databases on two different 
systems.  Thus, any hacker would not get total CC data unless he know our 
design.  Also stored the exp data and pin in different locations.  If someone 
knew the design, then the data was still at risk.  But much harder.

I do not advocate any particular design, and no, I was not thinking about double 
encryption.  Such stuff needs to be different, and not just more of the same 
(encryption or whatever).

Assume a hacker will break in, then think of ways to make it harder to actually 
cause harm.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486