Re: [SystemSafety] Modelling and coding guidelines: "Unambiguous Graphical Representation"

From: Steve Tockey < >
Date: Sat, 27 Feb 2016 09:11:02 +0000

One only needs to look at how difficult it is for a computer to generate a "truly random number" to understand how difficult it is to make a computer behave truly non-deterministically. There's a difference between "truly random/non-deterministic" and "so computationally complex that mimicking the behavior is next to impossible". Authentication, encryption, etc depend on computational complexity, not true randomness. Again, someone with a sufficiently powerful computer can break the encryption / authentication. Deterministically.

The game is for the computational complexity of a nonce to be out of reach of the unauthorized entity. As computers become more and more powerful (Moore's Law), it calls for constantly increasing computational complexity.

In a computer, nothing is truly random.


-----Original Message-----
From: Peter Bernard Ladkin <ladkin_at_xxxxxx Date: Saturday, February 27, 2016 12:57 AM To: Steve Tockey <Steve.Tockey_at_xxxxxx "systemsafety_at_xxxxxx <systemsafety_at_xxxxxx Subject: Re: [SystemSafety] Modelling and coding guidelines: "Unambiguous Graphical Representation"

On 2016-02-27 09:47 , Steve Tockey wrote:
> In safety critical systems, we should strive for specifications that are
> both unambiguous and deterministic, so that relevant safety properties
> be examined.

I'm not so sure. If your safety-critical system needs some security, which many or most of them do,
then it might need the ability to generate nonces, since many authentication and confidentiality
algorithms require them. A nonce is a value generated non-deterministically in most reliable
implementations. Indeed, the more deterministic it is, the less worthy it is.

PBL Prof. Peter Bernard Ladkin, Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany
Je suis Charlie
Tel+msg +49 (0)521 880 7319

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Sat Feb 27 2016 - 10:11:12 CET

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:07 CEST