comp.lang.ada
 help / color / mirror / Atom feed
* Canal+ crash
@ 2024-07-19 21:41 Nicolas Paul Colin de Glocester
  2024-07-20  7:23 ` Dmitry A. Kazakov
  0 siblings, 1 reply; 22+ messages in thread
From: Nicolas Paul Colin de Glocester @ 2024-07-19 21:41 UTC (permalink / raw)


Canal+ uses Ada but one is alleging that Canal+ suffered a crash today 
with Windows. Cf.
HTTPS://WWW.UniversFreeBox.com/article/568957/orange-canal-et-bouygues-telecom-annoncent-a-leurs-abonnes-etre-touches-par-la-panne-informatique-mondiale
Cf. a complaint by Mister Brukardt that Ada can not control non-Ada 
software on a shared system.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-19 21:41 Canal+ crash Nicolas Paul Colin de Glocester
@ 2024-07-20  7:23 ` Dmitry A. Kazakov
  2024-07-20  7:43   ` Lawrence D'Oliveiro
  0 siblings, 1 reply; 22+ messages in thread
From: Dmitry A. Kazakov @ 2024-07-20  7:23 UTC (permalink / raw)


On 2024-07-19 23:41, Nicolas Paul Colin de Glocester wrote:
> Canal+ uses Ada but one is alleging that Canal+ suffered a crash today 
> with Windows. Cf.
> HTTPS://WWW.UniversFreeBox.com/article/568957/orange-canal-et-bouygues-telecom-annoncent-a-leurs-abonnes-etre-touches-par-la-panne-informatique-mondiale
> Cf. a complaint by Mister Brukardt that Ada can not control non-Ada 
> software on a shared system.

It is not about Ada. It is about the fundamental principle that security 
cannot be added on top of an insecure system. The lesson never learned 
is that security levels impose safety problems not solving security 
issues. Modern security architectures are nothing but a huge scam.

Thank you Microsoft!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-20  7:23 ` Dmitry A. Kazakov
@ 2024-07-20  7:43   ` Lawrence D'Oliveiro
  2024-07-20  9:08     ` Dmitry A. Kazakov
  0 siblings, 1 reply; 22+ messages in thread
From: Lawrence D'Oliveiro @ 2024-07-20  7:43 UTC (permalink / raw)


On Sat, 20 Jul 2024 09:23:11 +0200, Dmitry A. Kazakov wrote:

> It is about the fundamental principle that security
> cannot be added on top of an insecure system.

Actually, it can. Notice how the Internet itself is horribly insecure, yet 
we are capable of running secure applications and protocols on top of it.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-20  7:43   ` Lawrence D'Oliveiro
@ 2024-07-20  9:08     ` Dmitry A. Kazakov
  2024-07-21  1:04       ` Lawrence D'Oliveiro
  0 siblings, 1 reply; 22+ messages in thread
From: Dmitry A. Kazakov @ 2024-07-20  9:08 UTC (permalink / raw)


On 2024-07-20 09:43, Lawrence D'Oliveiro wrote:
> On Sat, 20 Jul 2024 09:23:11 +0200, Dmitry A. Kazakov wrote:
> 
>> It is about the fundamental principle that security
>> cannot be added on top of an insecure system.
> 
> Actually, it can. Notice how the Internet itself is horribly insecure, yet
> we are capable of running secure applications and protocols on top of it.

Of course we can. That is the whole idea of the scam. Why on earth do we 
need security updates? Do you update your screwdriver each week?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-20  9:08     ` Dmitry A. Kazakov
@ 2024-07-21  1:04       ` Lawrence D'Oliveiro
  2024-07-21  7:22         ` Dmitry A. Kazakov
  0 siblings, 1 reply; 22+ messages in thread
From: Lawrence D'Oliveiro @ 2024-07-21  1:04 UTC (permalink / raw)


On Sat, 20 Jul 2024 11:08:47 +0200, Dmitry A. Kazakov wrote:

> On 2024-07-20 09:43, Lawrence D'Oliveiro wrote:
>
>> On Sat, 20 Jul 2024 09:23:11 +0200, Dmitry A. Kazakov wrote:
>> 
>>> It is about the fundamental principle that security cannot be added on
>>> top of an insecure system.
>> 
>> Actually, it can. Notice how the Internet itself is horribly insecure,
>> yet we are capable of running secure applications and protocols on top
>> of it.
> 
> Why on earth do we need security updates?

Because computer systems are complex, and new bugs keep being discovered 
all the time.

> Do you update your screwdriver each week?

I don’t depend on my screwdriver to keep my bank account secure.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-21  1:04       ` Lawrence D'Oliveiro
@ 2024-07-21  7:22         ` Dmitry A. Kazakov
  2024-07-21  8:00           ` Niklas Holsti
  2024-07-21 21:52           ` Lawrence D'Oliveiro
  0 siblings, 2 replies; 22+ messages in thread
From: Dmitry A. Kazakov @ 2024-07-21  7:22 UTC (permalink / raw)


On 2024-07-21 03:04, Lawrence D'Oliveiro wrote:
> On Sat, 20 Jul 2024 11:08:47 +0200, Dmitry A. Kazakov wrote:
> 
>> On 2024-07-20 09:43, Lawrence D'Oliveiro wrote:
>>
>>> On Sat, 20 Jul 2024 09:23:11 +0200, Dmitry A. Kazakov wrote:
>>>
>>>> It is about the fundamental principle that security cannot be added on
>>>> top of an insecure system.
>>>
>>> Actually, it can. Notice how the Internet itself is horribly insecure,
>>> yet we are capable of running secure applications and protocols on top
>>> of it.
>>
>> Why on earth do we need security updates?
> 
> Because computer systems are complex, and new bugs keep being discovered
> all the time.

This does not make sense. You can create a very complex system out of 
screwdrivers and still each screwdriver would require no update.

Systems consist of computers and computers of software modules. There is 
nothing inherently complex about making a module safe and bug free. 
Security interactions are primitive and 100% functional. There is no 
difficult issues with non-functional stuff like real-time problems. It 
is purely algorithmic while all mathematical complexity of cryptography 
is NOT what gets updated. It is complex only because it was designed as 
a Wood Block Tumbling Game.

>> Do you update your screwdriver each week?
> 
> I don’t depend on my screwdriver to keep my bank account secure.

I don't need a bank account to fasten the screws. Application area is 
irrelevant.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-21  7:22         ` Dmitry A. Kazakov
@ 2024-07-21  8:00           ` Niklas Holsti
  2024-07-21  9:10             ` J-P. Rosen
  2024-07-21  9:19             ` Dmitry A. Kazakov
  2024-07-21 21:52           ` Lawrence D'Oliveiro
  1 sibling, 2 replies; 22+ messages in thread
From: Niklas Holsti @ 2024-07-21  8:00 UTC (permalink / raw)


On 2024-07-21 10:22, Dmitry A. Kazakov wrote:
> On 2024-07-21 03:04, Lawrence D'Oliveiro wrote:
>> On Sat, 20 Jul 2024 11:08:47 +0200, Dmitry A. Kazakov wrote:
>>
>>> On 2024-07-20 09:43, Lawrence D'Oliveiro wrote:
>>>
>>>> On Sat, 20 Jul 2024 09:23:11 +0200, Dmitry A. Kazakov wrote:
>>>>
>>>>> It is about the fundamental principle that security cannot be added on
>>>>> top of an insecure system.
>>>>
>>>> Actually, it can. Notice how the Internet itself is horribly insecure,
>>>> yet we are capable of running secure applications and protocols on top
>>>> of it.
>>>
>>> Why on earth do we need security updates?
>>
>> Because computer systems are complex, and new bugs keep being discovered
>> all the time.
> 
> This does not make sense. You can create a very complex system out of 
> screwdrivers and still each screwdriver would require no update.
> 
> Systems consist of computers and computers of software modules. There is 
> nothing inherently complex about making a module safe and bug free. 
> Security interactions are primitive and 100% functional. There is no 
> difficult issues with non-functional stuff like real-time problems.


Well, several recent attacks use variations in execution timing as a 
side-channel to exfiltrate secrets such as crypto keys. The crypto code 
can be functionally perfect and bug-free, but it may still be open to 
attack by such methods.

But certainly, most attacks on SW have used functional bugs such as 
buffer overflows.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-21  8:00           ` Niklas Holsti
@ 2024-07-21  9:10             ` J-P. Rosen
  2024-07-21  9:34               ` Dmitry A. Kazakov
  2024-07-21 21:53               ` Lawrence D'Oliveiro
  2024-07-21  9:19             ` Dmitry A. Kazakov
  1 sibling, 2 replies; 22+ messages in thread
From: J-P. Rosen @ 2024-07-21  9:10 UTC (permalink / raw)


Le 21/07/2024 à 10:00, Niklas Holsti a écrit :
> But certainly, most attacks on SW have used functional bugs such as 
> buffer overflows.

A problem that has been solved since 1983, and even before (Pascal had 
bounds checking). Sigh...
-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
https://www.adalog.fr https://www.adacontrol.fr

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-21  8:00           ` Niklas Holsti
  2024-07-21  9:10             ` J-P. Rosen
@ 2024-07-21  9:19             ` Dmitry A. Kazakov
  2024-07-21 11:31               ` Niklas Holsti
  1 sibling, 1 reply; 22+ messages in thread
From: Dmitry A. Kazakov @ 2024-07-21  9:19 UTC (permalink / raw)


On 2024-07-21 10:00, Niklas Holsti wrote:
> On 2024-07-21 10:22, Dmitry A. Kazakov wrote:
>> On 2024-07-21 03:04, Lawrence D'Oliveiro wrote:
>>> On Sat, 20 Jul 2024 11:08:47 +0200, Dmitry A. Kazakov wrote:
>>>
>>>> On 2024-07-20 09:43, Lawrence D'Oliveiro wrote:
>>>>
>>>>> On Sat, 20 Jul 2024 09:23:11 +0200, Dmitry A. Kazakov wrote:
>>>>>
>>>>>> It is about the fundamental principle that security cannot be 
>>>>>> added on
>>>>>> top of an insecure system.
>>>>>
>>>>> Actually, it can. Notice how the Internet itself is horribly insecure,
>>>>> yet we are capable of running secure applications and protocols on top
>>>>> of it.
>>>>
>>>> Why on earth do we need security updates?
>>>
>>> Because computer systems are complex, and new bugs keep being discovered
>>> all the time.
>>
>> This does not make sense. You can create a very complex system out of 
>> screwdrivers and still each screwdriver would require no update.
>>
>> Systems consist of computers and computers of software modules. There 
>> is nothing inherently complex about making a module safe and bug free. 
>> Security interactions are primitive and 100% functional. There is no 
>> difficult issues with non-functional stuff like real-time problems.
> 
> Well, several recent attacks use variations in execution timing as a 
> side-channel to exfiltrate secrets such as crypto keys. The crypto code 
> can be functionally perfect and bug-free, but it may still be open to 
> attack by such methods.

It is always a tradeoff between the value of the information and costs 
of breaking the protection. I doubt that timing attack are much more 
feasible in that respect than brute force.

> But certainly, most attacks on SW have used functional bugs such as 
> buffer overflows.

Exactly. Non-functional attacks are hypothetical at best. They rely on 
internal knowledge which is another problem. An insider work is the most 
common case of all breaches. So, maybe, it is better to update the 
staff? (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-21  9:10             ` J-P. Rosen
@ 2024-07-21  9:34               ` Dmitry A. Kazakov
  2024-07-21 11:11                 ` Nicolas Paul Colin de Glocester
  2024-07-21 21:53               ` Lawrence D'Oliveiro
  1 sibling, 1 reply; 22+ messages in thread
From: Dmitry A. Kazakov @ 2024-07-21  9:34 UTC (permalink / raw)


On 2024-07-21 11:10, J-P. Rosen wrote:
> Le 21/07/2024 à 10:00, Niklas Holsti a écrit :
>> But certainly, most attacks on SW have used functional bugs such as 
>> buffer overflows.
> 
> A problem that has been solved since 1983, and even before (Pascal had 
> bounds checking). Sigh...

Yup, however some crackpot could always suggest an attack on bounds 
checking, e.g. exception vs. not, index to bounds comparison dependent 
on the actual values etc, and then produce a lengthy paper on a 
constructed absolutely unrealistic scenario... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-21  9:34               ` Dmitry A. Kazakov
@ 2024-07-21 11:11                 ` Nicolas Paul Colin de Glocester
  0 siblings, 0 replies; 22+ messages in thread
From: Nicolas Paul Colin de Glocester @ 2024-07-21 11:11 UTC (permalink / raw)


[-- Attachment #1: Type: text/plain, Size: 14353 bytes --]

On Sun, 21 Jul 2024, Dmitry A. Kazakov wrote:
"Yup, however some crackpot could always suggest an attack on bounds checking, 
e.g. exception vs. not, index to bounds comparison dependent on the actual 
values etc, and then produce a lengthy paper on a constructed absolutely 
unrealistic scenario... (:-))"

Hello,

Supposedly scientific journals are rife with evil unrealistic fraudulent 
papers which cause really deadly consequences. Cf. inter alia
@article {fulltext6.pdf,
    author = {Labb\'{e}, Cyril and Labb\'{e}, Dominique},
pages={379--396},
year={2013},
volume={94},
issue={1},
    title = {{Duplicate and fake publications in the scientific literature: 
how many SCIgen papers in computer science?}},
    journal = {Scientometrics},
    abstract = {Two kinds of bibliographic tools are used to retrieve 
scientific publications and make them available online. For one kind, 
access is free as they store information made publicly available online. 
For the other kind, access fees are required as they are compiled on 
information provided by the major publishers of scientific literature. The 
former can easily be interfered with, but it is generally assumed that the 
latter guarantee the integrity of the data they sell. Unfortunately, 
duplicate and fake publications are appearing in scientific conferences 
and, as a result, in the bibliographic services. We demonstrate a software 
method of detecting these duplicate and fake publications. Both the free 
services (such as Google Scholar and DBLP) and the charged-for services 
(such as IEEE Xplore) accept and index these publications.},
}
and 
@online{dieHimmelistschoen,
  author = {{Schlangemann (pseudonym)}, Herbert},
  title = {{The Official Herbert Schlangemann Blog}},
  url = {HTTP://dieHimmelistschoen.BlogSpot.com},
  year = {2008--2010}
  }
and
HTTP://Gloucester.Insomnia247.NL/Evil_which_is_so-called_science/

I myself wrote on 13th April 2012:
"On February 19th 2012, Nicholas Collin Paul de Glouceſter wrote:
|--------------------------------------------------------------------------------|
|"Dear Sir/Madam:                                                                |
|                                                                                |
|[. . .]                                                                         |
|                                                                                |
|I am a whistleblower and as such I am a victim of fraud,                        |
|much of which the Association for Computing Machinery                           |
|provided to people without publishing any of my attempts to                     |
|expose misconduct. Shame on you.                                                |
|                                                                                |
|I tried to expose fraud which I discovered when I applied                       |
|for a George Michael Memorial HPC Fellowship. An anonymous                      |
|reviewer wished me well and he or she advised me that I have                    |
|"other methods to ask for redress" but he or she left the                       |
|message too vague for me to take my complaints further. I                       |
|asked the Association for Computing Machinery for help in                       |
|obtaining more details as to which "other methods to ask for                    |
|redress" I have. I did not receive an answer to this                            |
|question. Why?                                                                  |
|                                                                                |
|Why does your website contain no warning that the paper                         |
|"OCCN: A Network-On-Chip Modeling and Simulation Framework",                    |
|DATE '04 is fraudulent? Shame on you.                                           |
|                                                                                |
|Yours sincerely,                                                                |
|Colin Paul Gloster                                                              |
|                                                                                |
|                                                                                |
|On October 6th, 2011, Nicholas Collin Paul de Glouceſter                        |
|sent questions to  ACMhelp@ACM.org  without receiving                           |
|answers:                                                                        |
|"On October 5th, 2011, Mail Delivery Subsystem <MAILER-DAEMON-ACM26-3@ACM.org>  |
|claimed:                                                                        |
||---------------------------------------------------------------------|         |
||"The original message was received at Wed, 05 Oct 2011 04:51:54 -0400|         |
||                                                                     |         |
||  ----- The following addresses had permanent fatal errors -----     |         |
||<lathrop@mcs.anl.gov>                                                |         |
||                                                                     |         |
||  ----- Transcript of session follows -----                          |         |
||.. while talking to mailgateway.anl.gov                              |         |
||>>> RCPT To:<lathrop@mcs.anl.gov>                                    |         |
||<<< 550 #5.1.0 Address rejected."                                    |         |
||---------------------------------------------------------------------|         |
|                                                                                |
|                                                                                |
|Gloster sent to  hpc-fellowship-questions@ACM.org  on October 5th,              |
|2011:                                                                           |
||---------------------------------------------------------------------|         |
||"Dear Sir/Madam,                                                     |         |
||                                                                     |         |
||As you would be aware, my application for a George Michael           |         |
||Memorial HPC Fellowship for 2011 failed.                             |         |
||                                                                     |         |
||Reviewer 3 was nice to comment:                                      |         |
||"Good luck with your research. A word of advice, this typy a         |         |
||submission is the forum to air the grievances you indicate. You have |         |
||other methods to ask for redress."                                   |         |
||                                                                     |         |
||I hope to be informed of details of how to proceed with airing the   |         |
||aforementioned grievances. What "other methods to ask for redress" do|         |
||I "have"?                                                            |         |
||                                                                     |         |
||Yours faithfully,                                                    |         |
||Nicholas Collin Paul de Glouceſter"                                  |         |
||---------------------------------------------------------------------|         |
|                                                                                |
|                                                                                |
|Dear Sir/Madam:                                                                 |
|                                                                                |
|I emailed  hpc-fellowship-questions@ACM.org  and so I received a bounce report  |
|for  lathrop@mcs.anl.gov  .                                                     |
|Has anyone actually received the email which I had sent to                      |
|hpc-fellowship-questions@ACM.org  ?                                             |
|                                                                                |
|I mentioned in one of the online surveys which you requested me to partake in   |
|after I left Italy that I am a victim of fraud published by ACM. In the         |
|fellowship application I mentioned two fraudulent papers published by ACM which |
|a so-called "tutor" had ordered me to praise (he and the coauthors are friends  |
|to each other). He himself had coauthored a similar fraudulent paper. I refused |
|to participate in this unethical activity. He censored my findings that they are|
|fraudsters and he said that if I would not quit then I would be failed for not  |
|having a publication.                                                           |
|                                                                                |
|I tried to expose this in "ACM Computing Surveys" and "The Journal of the ACM"  |
|but the manuscripts were rejected.                                              |
|                                                                                |
|It seems that one reviewer for the fellowship cared, but the advice given was   |
|not explicit enough for me to enact. Has the question reached that reviewer?    |
|                                                                                |
|Shall ACM retract fraudulent publications? When shall ACM                       |
|begin adhering to its own Code of Ethics?                                       |
|                                                                                |
|Yours faithfully,                                                               |
|Nicholas Collin Paul de Glouceſter""                                            |
|--------------------------------------------------------------------------------|


Dear Sir/Madam:

Why have I not yet received answers to any of the questions above?

Why does the ACM Portal of the Association for Computing Machinery show 
so-called "research" which was reported and proven to be fraudulent 
without warning that it is fraudulent?

Yours faithfully,
Colin Paul Gloster"

The ACM let be sent:
|--------------------------------------------------------------------------------------------|
|"25-Aug-2010                                                                                |
|                                                                                            |
|Dear Mr. de Glouceſter,                                                                     |
|                                                                                            |
|I am sorry to inform you that your paper has been rejected. Unfortunately, ACM Computing    |
|Surveys is able to accept only a rather small percentage of the submissions it receives.    |
|                                                                                            |
|I have read your paper.  It is clear that you feel that you have a grievance against the    |
|University of Pisa and the SHAPES group.  I am not prepared to let you use ACM Computing    |
|Surveys as a vehicle for publicising that grievance.  The language that you have used in the|
|paper is intemperate and would potentially lead to legal problems for the ACM if we were to |
|publish it.                                                                                 |
|                                                                                            |
|Sincerely,                                                                                  |
|                                                                                            |
|Chris Hankin                                                                                |
|Editor-in-Chief                                                                             |
|ACM Computing Surveys"                                                                      |
|--------------------------------------------------------------------------------------------|

"[. . .]

* 7. Why did you let your membership to ACM lapse? Please select all that 
apply.

I didn’t see the value in my membership
[. . .]
Too expensive
[. . .]
Other (please specify)
I had complained to you about subsidy fraud which you publish (I used to 
work under a coauthor fraudster). You refuse to retract it so you are 
accomplices so a subsidy fraudster got away with perpetrating perjury 
covering up this fraud so he went on to murder 3 men.
[. . .]
* 9. Would you consider renewing your ACM membership in the future?
[. . .]
No
[. . .]
10. Please share what would compel you to become a member of ACM again.
Please publish errata and retractions and apologies. Testify against 
scientific malconduct instead of pretending that you adhere to your "Code 
of Ethics". Resurrect the victims whose murders you are guilty of in 2nd 
or 3rd degrees. Repair my reputation. Refuse to publish baloney. Arrange a 
fair PhD exam for me (I whistleblow against a PhD so-called "tutor" so I 
am denied even a dissertation defense!). Make amends."
wrote I myself on
HTTPS://WWW.research.net/r/FPSC3KH
on April 20th, 2024. This survey stated that the Association for Computing 
Machinery wants to contact me afterwards to try to get me to join, but 3 
months and 1 day afterwards I still do not get a follow-up.

Note by the way that a court made a final unappealable court order for a 
PhD scholarship to be paid to myself but such a defendant refuses to obey 
such an order. Note also that a court made orders to allow me to go to a 
university but such a putative university disobeyed such orders and 
instead got armed professional combatants to hit me out even though I did 
not threaten (confirmed by a district attorney); I myself did not fight 
(confirmed by CCTV); and I did not have a weapon (confirmed by policemen). 
Cf.
HTTPS://WWW.COE.int/fr/web/cpt/portugal

Sincères salutations.



Nicolas Paul Colin de Glocester

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-21  9:19             ` Dmitry A. Kazakov
@ 2024-07-21 11:31               ` Niklas Holsti
  2024-07-21 16:49                 ` Dmitry A. Kazakov
  0 siblings, 1 reply; 22+ messages in thread
From: Niklas Holsti @ 2024-07-21 11:31 UTC (permalink / raw)


On 2024-07-21 12:19, Dmitry A. Kazakov wrote:
> On 2024-07-21 10:00, Niklas Holsti wrote:
>> On 2024-07-21 10:22, Dmitry A. Kazakov wrote:
>>> On 2024-07-21 03:04, Lawrence D'Oliveiro wrote:
>>>> On Sat, 20 Jul 2024 11:08:47 +0200, Dmitry A. Kazakov wrote:
>>>>
>>>>> On 2024-07-20 09:43, Lawrence D'Oliveiro wrote:
>>>>>
>>>>>> On Sat, 20 Jul 2024 09:23:11 +0200, Dmitry A. Kazakov wrote:
>>>>>>
>>>>>>> It is about the fundamental principle that security cannot be 
>>>>>>> added on
>>>>>>> top of an insecure system.
>>>>>>
>>>>>> Actually, it can. Notice how the Internet itself is horribly 
>>>>>> insecure,
>>>>>> yet we are capable of running secure applications and protocols on 
>>>>>> top
>>>>>> of it.
>>>>>
>>>>> Why on earth do we need security updates?
>>>>
>>>> Because computer systems are complex, and new bugs keep being 
>>>> discovered
>>>> all the time.
>>>
>>> This does not make sense. You can create a very complex system out of 
>>> screwdrivers and still each screwdriver would require no update.
>>>
>>> Systems consist of computers and computers of software modules. There 
>>> is nothing inherently complex about making a module safe and bug 
>>> free. Security interactions are primitive and 100% functional. There 
>>> is no difficult issues with non-functional stuff like real-time 
>>> problems.
>>
>> Well, several recent attacks use variations in execution timing as a 
>> side-channel to exfiltrate secrets such as crypto keys. The crypto 
>> code can be functionally perfect and bug-free, but it may still be 
>> open to attack by such methods.
> 
> It is always a tradeoff between the value of the information and costs 
> of breaking the protection. I doubt that timing attack are much more 
> feasible in that respect than brute force.


Security researchers and crypto implementers seem to take timing attacks 
quite seriously, putting a lot of effort into making the crucial crypto 
steps run in constant time.


>> But certainly, most attacks on SW have used functional bugs such as 
>> buffer overflows.
> 
> Exactly. Non-functional attacks are hypothetical at best. They rely on 
> internal knowledge which is another problem. 


As I understand it, the "internal knowledge" needed for timing attacks 
is mostly what is easily discoverable from the open source-code of the 
SW that is attacked.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-21 11:31               ` Niklas Holsti
@ 2024-07-21 16:49                 ` Dmitry A. Kazakov
  2024-07-21 21:55                   ` Lawrence D'Oliveiro
  0 siblings, 1 reply; 22+ messages in thread
From: Dmitry A. Kazakov @ 2024-07-21 16:49 UTC (permalink / raw)


On 2024-07-21 13:31, Niklas Holsti wrote:

> Security researchers and crypto implementers seem to take timing attacks 
> quite seriously, putting a lot of effort into making the crucial crypto 
> steps run in constant time.

Cynically: they certainly know how to butter their bread...

> As I understand it, the "internal knowledge" needed for timing attacks 
> is mostly what is easily discoverable from the open source-code of the 
> SW that is attacked.

Considering many many layers of software to predict timing from code in 
uncontrolled environment would be a challenge.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-21  7:22         ` Dmitry A. Kazakov
  2024-07-21  8:00           ` Niklas Holsti
@ 2024-07-21 21:52           ` Lawrence D'Oliveiro
  2024-07-22  7:16             ` Dmitry A. Kazakov
  1 sibling, 1 reply; 22+ messages in thread
From: Lawrence D'Oliveiro @ 2024-07-21 21:52 UTC (permalink / raw)


On Sun, 21 Jul 2024 09:22:06 +0200, Dmitry A. Kazakov wrote:

> On 2024-07-21 03:04, Lawrence D'Oliveiro wrote:
>
>> On Sat, 20 Jul 2024 11:08:47 +0200, Dmitry A. Kazakov wrote:
>> 
>>> Why on earth do we need security updates?
>> 
>> Because computer systems are complex, and new bugs keep being
>> discovered all the time.
> 
> This does not make sense. You can create a very complex system out of
> screwdrivers and still each screwdriver would require no update.

There is an old engineering adage, that the complexity of a system arises, 
not so much from the number of individual components, as from the number 
of potential interactions between them.

If you have a box full of screwdrivers, then all you have is a box full of 
screwdrivers.

If you have a computer system made up of a bunch of modules interacting 
with each other, then you could have, potentially, quite a complex system 
indeed.

Look up the term “combinatorial explosion” to learn more.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-21  9:10             ` J-P. Rosen
  2024-07-21  9:34               ` Dmitry A. Kazakov
@ 2024-07-21 21:53               ` Lawrence D'Oliveiro
  2024-07-22  6:36                 ` J-P. Rosen
  1 sibling, 1 reply; 22+ messages in thread
From: Lawrence D'Oliveiro @ 2024-07-21 21:53 UTC (permalink / raw)


On Sun, 21 Jul 2024 11:10:06 +0200, J-P. Rosen wrote:

> Le 21/07/2024 à 10:00, Niklas Holsti a écrit :
>
>> But certainly, most attacks on SW have used functional bugs such as
>> buffer overflows.
> 
> A problem that has been solved since 1983, and even before (Pascal had
> bounds checking). Sigh...

Pascal had no checking for memory leaks or double-frees.

Rust certainly seems to be a next-generation solution to these sorts of 
memory problems.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-21 16:49                 ` Dmitry A. Kazakov
@ 2024-07-21 21:55                   ` Lawrence D'Oliveiro
  0 siblings, 0 replies; 22+ messages in thread
From: Lawrence D'Oliveiro @ 2024-07-21 21:55 UTC (permalink / raw)


On Sun, 21 Jul 2024 18:49:27 +0200, Dmitry A. Kazakov wrote:

> Considering many many layers of software to predict timing from code in
> uncontrolled environment would be a challenge.

And yet it has been successfully done on the hardware itself, right down 
under all those layers of software (cf Spectre/Meltdown).

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-21 21:53               ` Lawrence D'Oliveiro
@ 2024-07-22  6:36                 ` J-P. Rosen
  2024-07-23  1:48                   ` Lawrence D'Oliveiro
  0 siblings, 1 reply; 22+ messages in thread
From: J-P. Rosen @ 2024-07-22  6:36 UTC (permalink / raw)


Le 21/07/2024 à 23:53, Lawrence D'Oliveiro a écrit :
> On Sun, 21 Jul 2024 11:10:06 +0200, J-P. Rosen wrote:
> 
>> Le 21/07/2024 à 10:00, Niklas Holsti a écrit :
>>
>>> But certainly, most attacks on SW have used functional bugs such as
>>> buffer overflows.
>>
>> A problem that has been solved since 1983, and even before (Pascal had
>> bounds checking). Sigh...
> 
> Pascal had no checking for memory leaks or double-frees.
> 
> Rust certainly seems to be a next-generation solution to these sorts of
> memory problems.

We were talking about bounds checking, that Pascal had.
Nowadays, you should not use pointers directly, but containers. Pointers 
are necessary only for writing containers, thanks to Ada's features not 
found in other languages, like allocating dynamically sized arrays on 
the stack.

Note that in Rust, containers are written using unsafe Rust, therefore 
Rust is not better than Ada on that aspect, it is a complicated solution 
to a problem that Ada doesn't have.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
https://www.adalog.fr https://www.adacontrol.fr

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-21 21:52           ` Lawrence D'Oliveiro
@ 2024-07-22  7:16             ` Dmitry A. Kazakov
  2024-07-23  1:49               ` Lawrence D'Oliveiro
  0 siblings, 1 reply; 22+ messages in thread
From: Dmitry A. Kazakov @ 2024-07-22  7:16 UTC (permalink / raw)


On 2024-07-21 23:52, Lawrence D'Oliveiro wrote:
> On Sun, 21 Jul 2024 09:22:06 +0200, Dmitry A. Kazakov wrote:

> If you have a box full of screwdrivers, then all you have is a box full of
> screwdrivers.
> 
> If you have a computer system made up of a bunch of modules interacting
> with each other, then you could have, potentially, quite a complex system
> indeed.

Tight coupling = bad design. No difference to screwdrivers. However you 
can take integer arithmetic if you dislike screwdrivers. However complex 
system you build, there is no need to update integers.

> Look up the term “combinatorial explosion” to learn more.

Bad design leads to explosion of non-trivial unanticipated system states 
making it unpredictable. This is what happens when you add security on 
top. You patch holes drilling new ones to fix the patches.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-22  6:36                 ` J-P. Rosen
@ 2024-07-23  1:48                   ` Lawrence D'Oliveiro
  0 siblings, 0 replies; 22+ messages in thread
From: Lawrence D'Oliveiro @ 2024-07-23  1:48 UTC (permalink / raw)


On Mon, 22 Jul 2024 08:36:08 +0200, J-P. Rosen wrote:

> Le 21/07/2024 à 23:53, Lawrence D'Oliveiro a écrit :
>> On Sun, 21 Jul 2024 11:10:06 +0200, J-P. Rosen wrote:
>> 
>>> Le 21/07/2024 à 10:00, Niklas Holsti a écrit :
>>>
>>>> But certainly, most attacks on SW have used functional bugs such as
>>>> buffer overflows.
>>>
>>> A problem that has been solved since 1983, and even before (Pascal had
>>> bounds checking). Sigh...
>> 
>> Pascal had no checking for memory leaks or double-frees.
>> 
>> Rust certainly seems to be a next-generation solution to these sorts of
>> memory problems.
> 
> We were talking about bounds checking, that Pascal had.

Which is only one potential pitfall for bugs with security implications.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-22  7:16             ` Dmitry A. Kazakov
@ 2024-07-23  1:49               ` Lawrence D'Oliveiro
  2024-07-23  7:06                 ` Dmitry A. Kazakov
  0 siblings, 1 reply; 22+ messages in thread
From: Lawrence D'Oliveiro @ 2024-07-23  1:49 UTC (permalink / raw)


On Mon, 22 Jul 2024 09:16:09 +0200, Dmitry A. Kazakov wrote:

> On 2024-07-21 23:52, Lawrence D'Oliveiro wrote:
>> On Sun, 21 Jul 2024 09:22:06 +0200, Dmitry A. Kazakov wrote:
> 
>> If you have a box full of screwdrivers, then all you have is a box full
>> of screwdrivers.
>> 
>> If you have a computer system made up of a bunch of modules interacting
>> with each other, then you could have, potentially, quite a complex
>> system indeed.
> 
> Tight coupling = bad design.

And yet you are relying on those systems right now. Do you do online 
payments/banking? You depend on those systems crucially for that.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-23  1:49               ` Lawrence D'Oliveiro
@ 2024-07-23  7:06                 ` Dmitry A. Kazakov
  2024-07-23  8:36                   ` Lawrence D'Oliveiro
  0 siblings, 1 reply; 22+ messages in thread
From: Dmitry A. Kazakov @ 2024-07-23  7:06 UTC (permalink / raw)


On 2024-07-23 03:49, Lawrence D'Oliveiro wrote:
> On Mon, 22 Jul 2024 09:16:09 +0200, Dmitry A. Kazakov wrote:
> 
>> On 2024-07-21 23:52, Lawrence D'Oliveiro wrote:
>>> On Sun, 21 Jul 2024 09:22:06 +0200, Dmitry A. Kazakov wrote:
>>
>>> If you have a box full of screwdrivers, then all you have is a box full
>>> of screwdrivers.
>>>
>>> If you have a computer system made up of a bunch of modules interacting
>>> with each other, then you could have, potentially, quite a complex
>>> system indeed.
>>
>> Tight coupling = bad design.
> 
> And yet you are relying on those systems right now. Do you do online
> payments/banking? You depend on those systems crucially for that.

I don't understand your point. Should I bubble with joy each time it 
crashes or gets compromised?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Canal+ crash
  2024-07-23  7:06                 ` Dmitry A. Kazakov
@ 2024-07-23  8:36                   ` Lawrence D'Oliveiro
  0 siblings, 0 replies; 22+ messages in thread
From: Lawrence D'Oliveiro @ 2024-07-23  8:36 UTC (permalink / raw)


On Tue, 23 Jul 2024 09:06:26 +0200, Dmitry A. Kazakov wrote:

> On 2024-07-23 03:49, Lawrence D'Oliveiro wrote:
>
>> On Mon, 22 Jul 2024 09:16:09 +0200, Dmitry A. Kazakov wrote:
>> 
>>> On 2024-07-21 23:52, Lawrence D'Oliveiro wrote:
>>>> On Sun, 21 Jul 2024 09:22:06 +0200, Dmitry A. Kazakov wrote:
>>>
>>>> If you have a box full of screwdrivers, then all you have is a box
>>>> full of screwdrivers.
>>>>
>>>> If you have a computer system made up of a bunch of modules
>>>> interacting with each other, then you could have, potentially, quite
>>>> a complex system indeed.
>>>
>>> Tight coupling = bad design.
>> 
>> And yet you are relying on those systems right now. Do you do online
>> payments/banking? You depend on those systems crucially for that.
> 
> I don't understand your point. Should I bubble with joy each time it
> crashes or gets compromised?

You seem to say one thing and do another, is my point.

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2024-07-23  8:36 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-07-19 21:41 Canal+ crash Nicolas Paul Colin de Glocester
2024-07-20  7:23 ` Dmitry A. Kazakov
2024-07-20  7:43   ` Lawrence D'Oliveiro
2024-07-20  9:08     ` Dmitry A. Kazakov
2024-07-21  1:04       ` Lawrence D'Oliveiro
2024-07-21  7:22         ` Dmitry A. Kazakov
2024-07-21  8:00           ` Niklas Holsti
2024-07-21  9:10             ` J-P. Rosen
2024-07-21  9:34               ` Dmitry A. Kazakov
2024-07-21 11:11                 ` Nicolas Paul Colin de Glocester
2024-07-21 21:53               ` Lawrence D'Oliveiro
2024-07-22  6:36                 ` J-P. Rosen
2024-07-23  1:48                   ` Lawrence D'Oliveiro
2024-07-21  9:19             ` Dmitry A. Kazakov
2024-07-21 11:31               ` Niklas Holsti
2024-07-21 16:49                 ` Dmitry A. Kazakov
2024-07-21 21:55                   ` Lawrence D'Oliveiro
2024-07-21 21:52           ` Lawrence D'Oliveiro
2024-07-22  7:16             ` Dmitry A. Kazakov
2024-07-23  1:49               ` Lawrence D'Oliveiro
2024-07-23  7:06                 ` Dmitry A. Kazakov
2024-07-23  8:36                   ` Lawrence D'Oliveiro

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox