isn’t qwyittalk™ unbreakable?qwyit.com/assets/files/qwyittalk-unbreakable-v1.2-with...qwyit llc...

Qwyit LLC Isn’t QwyitTalk™ Unbreakable?

Qwyit LLC www.qwyit.com of 26

Isn’t QwyitTalk™ Unbreakable? (Yes, but don’t tell anyone…..)

Discussion Version 1.0 January 2018

Sometimes, you got to believe before you See the Proof.

You can wait a lifetime for a Moment of Truth.

Sometimes, all it takes is a Leap Of Faith.

- Delbert McClinton

Author: Mr. Paul McGough, CTO, Qwyit LLC

Copyright Notice Copyright © 2018 Qwyit LLC. All Rights Reserved. Abstract This paper provides a discussion: somewhat scientific, more engineering, leaning toward technical with just a dash of philosophy. As a pre-requisite to this discussion, it’s important to first read the QwyitTalk™ Overview, the QwyitTalk™ and Qwyit™ reference guides, as well as any and all of our papers and presentations.



Contents PART 1 – What is Unbreakable? ............................................................................................................................ 3

Introduction......................................................................................................................................................... 3

What Is An Unbreakable Cipher? – Let’s Review .............................................................................................. 3

What Is An Unbreakable CryptoSystem? ............................................................................................................ 4

Building an Unbreakable Cryptosystem: How To .............................................................................................. 5

Keys! ................................................................................................................................................................... 6

Part II – Unbreakable QwyitTalk™ ....................................................................................................................... 8

QwyitTalk™ Core Processes .............................................................................................................................. 8

Initial Authentication Token/Credential Distribution (Verified Setup – VSU) ................................................... 8

Per Message Token/Credential Distribution (Authentication Handshake – AH) and Messaging

(QwyitTalk™Cipher) .......................................................................................................................................... 9

The Qwyit™ Cipher ...................................................................................................................................... 10

Part III – The QwyitTalk™ Challenges ................................................................................................................ 10

QwyitTalk™ Challenge #1 – Separate, Unique DSKs ................................................................................. 12

QwyitTalk™ Challenge #2 – Identical unique CT, Same PT ....................................................................... 14

QwyitTalk™ Challenge #3 – Identical same CT, Different PT .................................................................... 16

QwyitTalk™ Challenge #4 – A Message Test .............................................................................................. 18

QDS ............................................................................................................................................................... 19

Client1 ........................................................................................................................................................... 20

Client2 ........................................................................................................................................................... 21

Client1 ........................................................................................................................................................... 22

Client2 ........................................................................................................................................................... 23

Client1 ........................................................................................................................................................... 23

Afterward .......................................................................................................................................................... 24

References ......................................................................................................................................................... 24

Epilogue ............................................................................................................................................................ 24

Appendix A – A Bit More .................................................................................................................................. 25

Notes from the Author ................................................................................................................................... 25



QwyitTalk™ - The First Unbreakable Crypto System,

Delivering The Second Unbreakable Cipher

This document details the provable security (unbreakable) of the QwyitTalk™ Authentication and Encryption Service (QwyitTalk™, QT™), Security as a Service. For more on the full Qwyit protocol, and QwyitTalk™ in particular, go to www.qwyit.com. PART 1 – What is Unbreakable? Introduction What would you do, if you invented something…well…something outrageously powerful, dynamically capable – oh – and something everyone already knows can’t be invented?! Like…say…a way to do Cold Fusion in an old soup can – or a lasts-forever battery made out of things from your first grade elementary school pencil box. You get the idea: you’re not going to be believed. You’ll try. You’ll actually build a demo of it and take it around…showing it…but you won’t actually claim that it’s what it is…because, well – you can’t do THAT! They won’t take you seriously, so…you couch it, dance around it, but – it’s still right in there! People will ignore you. Or they’ll say things like: ‘That’s really interesting…that…component…but – what’s the killer app for it?’ Now the first time you hear that, you’re thinking: ‘Great! They love it! And it’s got value…so…I’ll monetize it!!’ But…you’ll struggle…because: Nobody Cares. There’s just one little problem: They already have a solution. An answer. It’s called The Status Quo. And that is one tough cookie! So you’ll struggle…and most of those ‘Who Change The World’, well….they’re…Lucky. Or maybe just persistent. Or maybe it’s a combination of the two. This discussion is just another serve over the net – let’s see if we can change the world! What Is An Unbreakable Cipher? – Let’s Review http://www.cs.miami.edu/home/burt/learning/Csc609.051/notes/02.html Take a quick look to review the proof of a one-time-pad, an OTP. This paper won’t go into the math – it’s redundant: as mentioned in that article “The intuition is that any message can be transformed into any

cipher (of the same length) by a pad, and all transformations are equally likely.” That’s enough to explain it – if any result can’t be differentiated from any possibility, then there’s not even a universe’s worth of time to figure it out: it’s unbreakable. In order to build an unbreakable cryptosystem, we need to deliver an OTP authentically to every participant, whenever they need one to communicate unbreakably with any other participant. It seems Cryptography has abandoned looking into solutions for OTP key delivery for any number of reasons – but since it’s a straight line from a single use, unique key bit for every PT bit to unbreakable, if a delivery system of those keys (method and process) can be shown to meet the same unique, single-use standard, that straight line continues to an unbreakable cryptosystem.

http://www.qwyit.com/

http://www.cs.miami.edu/home/burt/learning/Csc609.051/notes/02.html



Oh…and there’s this: If any part of the use of this unbreakable cryptosystem takes ‘too long’, then it’s useless. Here’s Real World: The use of this cryptosystem’s management/delivery of OTPs (keys), and the step of encrypting/decrypting the messages using the keys can’t take any longer than it does now to send the messages in open, public format. That’s a fairly stern criteria to meet, but…it’s absolutely true. Whether or not it’s fair, it’s us that’s caused that constraint: see, no one will use the system if its slow – and ‘slow’ is measured by what we’re used to – and what we’re used to is the timing of open system communication (i.e., we won’t wait any longer than we do now, where everything is open and insecure and the timing that we’ve already ‘mandated’ through our acceptance of the current communication networks is defined by the network protocols – oh – and we aren’t going to do anything new either, like have to remember passphrases or anything more than a phone number – we can and already do that). So – IF our perfect, unbreakable cryptosystem delivering keys and being used to encrypt/decrypt takes longer than the noise of the network (already existing protocol timing), and/or requires us to ‘do stuff’, it’s useless. What Is An Unbreakable CryptoSystem? Here’s another unsolvable ‘intuition’: a + b = 7

Theorem. Every homogeneous system has either exactly one solution or infinitely many

solutions. If a homogeneous system has more unknowns than equations, then it has infinitely

many solutions.

Proof. Indeed, as we said the first statement directly follows from the theorem about

solutions of systems of linear equations. The second statement follows from the fact that if

the number of unknowns is bigger than the number of equations then some unknowns are

free, and as we saw, if we have a free unknown, we get infinitely many solutions. –

https://math.vanderbilt.edu/sapirmv/msapir/prth2.html

This is an underdetermined system, specifically, a consistent underdetermined system. If you and I know a, we’re the only ones who know b for certain – everyone else’s answers are equally likely. QwyitTalk™ is an underdetermined system of linear equations. And although linear systems are usually deemed weak and easily manipulated and completely dismissed by today’s crypto community, unfortunately, they are the only type of solution that can deliver, as a just-noted requirement, in Real World, Real Time. The entire success of an underdetermined, linear system – our QT™ cryptosystem – is building those equations to not only deliver OTP’s (unbreakable), but to make sure it contains all of the necessary one-way gates and other required communication properties (non-repudiation, etc., etc.) We’re going to use empirical constructs of QwyitTalk™ in this paper – all the math can be written later

https://math.vanderbilt.edu/sapirmv/msapir/jan10.shtml#th1

https://math.vanderbilt.edu/sapirmv/msapir/prth2.html



(combinatorial probabilities, crypto-descriptions, etc.) We’ll show that the system is unsolvable, and we’ll take you through examples, and hopefully, you’ll agree that it is unbreakable too. And there’s a challenge at the end – break it, and you can prove us wrong. Building an Unbreakable Cryptosystem: How To Way back when I first started (1997), my brother and I had a conversation about single sign-on, and he told me he didn’t have any problems using multiple logins. Not that he’s got a photographic memory or anything, but he had ‘a system’. He kept a little yellow sticky on his monitor with all his passwords on it (sounds pretty insecure, right?!) No…he made all his passwords into PINS, so they were just numbers. Then he wrote them all down on that sticky by putting them, scrambled into a matrix, 5x5 (or 6x6…something, in a square) – and all he had to do was remember where to start in the matrix. He just had to remember to start in the 2nd column, 4th row down. That wasn’t his first digit, it was just the number that told him where to go next, column-wise – then, keeping that number, he added it to where that number told him to go, row-wise and used that value. Those two numbers added together was his first PIN digit…and then he repeated that, using the next digit to the right of where he stopped, to get the next digit…(yes, if he ‘fell off the end’, he circled back to the start!)…and so on. This was a system where numbers are permuted upon itself, and with other pointers. These are a one-way function: the result doesn’t leak any information about its inputs. The next thing he told me was that he used the first PIN to then get the next one by simply adding the 1st and 2nd digits to get a value, and the 4th and 5th digits to get another value – and those two were the next column/row start of the next PIN. Hopefully, you noticed that one can’t ‘go backwards’ from the 2nd Pin to get the 1st – another one-way function. Also, hopefully you noticed that the PIN matrix can be used over and over and over again without losing any of its cryptographic entropy – simple rearrangement of the numbers and starting point doesn’t lose any of its effectiveness. This yields a very useful fact: Random numbers permuted with themselves remain random, especially if the method of permutation is underdetermined. Lastly, you noticed that when numbers ‘hide’ other numbers, the equations are unsolvable – there is no context or frame of reference for any solution. These features became the QwyitTalk™ PDAF, OWC and the Combine And Extract. The ‘things’ needed to build an unbreakable cryptosystem with embedded authentication and on-the-fly OTP message keys. (Please see the Ref Docs for full descriptions of these primitives and their capabilities.) These primitives, built with underdetermined linear equations, are the ‘things’ needed to turn a linear system into an unbreakable cryptosystem:

The One Way Cut (OWC) is an extremely computationally efficient one-way gate. It has been used by some of our Japanese cohorts in a few of their awarded cryptographic patents

o The OWC one-way gate mathematically stops one getting from one equation to the next: there isn’t any way to recognize either possible input from any other based on any known result, let alone the correct ones



The PDAF (Position Digit Algebra Function) is an incredibly efficient random number ‘generator’ (creator, actually)

o There is a ‘philosophy’ of randomness that isn’t accounted for in ‘traditional’ mathematics (at least we’re not aware of it – but it may well certainly exist): rearranging a random number, in a manner that is unsolvable, retains its randomness, whether or not it would pass some ‘statistical measurement’

Empirically, this is: “1234” is random. Mod10 addition of an unknown, second random number “4321”, generated by ‘reaching into’ and selecting digits from the first number using a second number or even from itself, for example leads to “6338”, which is as random as its two inputs since all of the numbers are contained in underdetermined equations

This simple Modular addition can continually rearrange the randomness, retaining digit distributions, etc. – as long as the weakness of tending to a single digit result in every position is never allowed (i.e., IF one approaches such results, simply reseed the starting random values – we don’t believe this ever happens, but…it might)

o This process, empirically, can be performed significantly more times than it would ever need to occur in any implementation

o The PDAF has wonderfully variant means in which to perform Random Rearrangement, as we’ll call this property, such that it can be implemented to pass ‘statistical measurement’.

But, passing a measurement that is never pertinent isn’t anything of value o The PDAF has an additional property of Selective Update, as we’ll call the property of

using its structure and/or values to ‘ephemerally’ update itself, randomly and ‘underdeterminedly’, in the same manner by two shared parties without any connection between them. The result is one-way gate protected (always underdetermined) from recovering the original, starting values (providing Perfect Forward Secrecy of every message)

The Combine and Extract are simply the PDAF in two parts, for efficiency and performance o They retain the same Random Rearrangement property o They are not used for Selective Update only because the PDAF has more flexibility

(results can be longer than the input, as well as operating on itself without any pointer key – see the ref docs for complete description)

The QwyitTalk™ fundamentals are now in place. Let’s discus their inputs. Keys! Keys should have 2 parts (No, not asynchronous):

They should have a part that relates to its use

They should have a second part that relates to changing itself (and never used ‘through’ to any end result)

When the 1st part is used – the part that makes child keys for encryption – That part should be an OTP. Then use the ‘secret’ 2nd part (i.e., never used for anything other than this) to swap out that 1st part – every time you use it.



Therefore, if we have a Key, in 2 parts, that changes every time we use it, and we add the other ingredients (our primitives for operations) into the process, we have Unbreakable:

If one starts with a truly random Authentication key, in 2 parts o Initial, secure delivery can be accomplished, as noted with several possible methods in

our papers, where performance is not an issue (Banks still mail PINs)

If one can use that key in 2 parts completely (Mathematically) separated by purpose o If the Method of separation is unsolvable math with one way gates

If one can build truly random child Encryption keys from one Authentication key part completely (mathematically) separated by purpose

o If the Method of separation is unsolvable math with one way gates

If one can use the Encryption key only one time, on the same length Plaintext (True OTP)

If any and all keys can be updated after every use o If the Method of update is unsolvable math with one way gates

Then the cryptosystem is Unbreakable. Especially when the only thing that all of the keys in the system secure (authenticate and encrypt) are numbers except the end Child Encryption Keys of the intended participants: Unbreakable. QwyitTalk is such a system, and is the First Provably Secure, Unbreakable, Unsolvable (pick your descriptor) Cryptosystem. Second Provably Secure cipher (since it is just a replay of the original OTP…the keys aren’t code books or documents, they’re truly random n-bit unique one-time-only use child keys made using math and one way gates.) Summarize:

QwyitTalk™ is an underdetermined system of equations – these are unsolvable

QwyitTalk™ is a pass-through trust model, where keys are important, while completely unimportant and disposable (See the QwyitTalk™ Overview for this introduction/discussion)

QwyitTalk™ provides a key management system whereby each participant has a unique OTP key that is used to talk 100% authentically and 100% securely to any other participant

QwyitTalk™ performs this key management with two processes o Verified Setup Up (VSU) o Authentication Handshake (AH)

QwyitTalk™ processes result in the delivery of 100% private authentication key pairs for each unique P2P communication

The Qwyit™ Cipher delivers a 100% unbreakable OTP, using a new, mathematically underdetermined encryption bit (not a fiddled bit) for each plaintext bit

Therefore: QwyitTalk™ as a cryptosystem is Unbreakable, and delivers the unbreakable Qwyit™ OTP cipher

Here’s QwyitTalk™, again, with a discussion of the three processes: Initial Key Distribution (Verified Setup, VSU), Authentication Handshake (AH) and the QT™ stream cipher (Messaging). Then there are the QwyitTalk™ Challenges. These deliver unbreakable proof.



Part II – Unbreakable QwyitTalk™ QwyitTalk™ Core Processes As a summation that can be found in detail in the Ref docs and our other papers, QwyitTalk™ is an exact replication of TLS; and that the processes defined by TLS are the agreed-upon, necessary information exchanges in order to authenticate and secure messaging. We’re focused here on unbreakable security, but the exact benefits of QT™ over TLS in performance, efficiency and improvement are substantial – see the docs. Initial Authentication Token/Credential Distribution (Verified Setup – VSU)

Architecture (Example method)

The QwyitTalk™ Reference Guide has a great deal of information on example methods for initial distribution (the VSU) of QT™ starting MQK and MEK keys – which together make up the 512-bit DSK (current recommended length.) Since it is a requirement of keeping the system secure (not unbreakable), for this paper, and every example and Challenge in it, the assumption is the same as for that of the Unbreakable OTP: each participant has been delivered their unique key in a 100% secure manner. So: A VSU has happened, all the QwyitTalk™ Clients have secure unique DSKs in two parts, MQKs and MEKs, and now we’re going to talk authentically and securely to each other – in any format, app, protocol, configuration (1-1, 1-many, many-1, etc.).

QwyitTalk™ Verified Set Up (VSU)

VSC1HTTPS Request QT™ Client

QT™ Service

VSQ2 HTTPS MQK Reply

VSQ3 Email MEK reply

VSC5 QT™ Confirmation

VSQ4 SMS MEK reply

QwyitTalk™ Verified Set Up (VSU)

The VSU is like a Passport…or Driver’s License…or even a Birth

Certificate: they rely on each other, have some kind of process to

minimize fraud and deception…aren’t perfect…and generally

shouldn’t be assumed to be Important, but they mistakenly are.

QT™ can implement any system for Initial Key Distribution that

anyone/everyone feels is ‘good’: HTTPS, mail, email, phone, UPS,

drone, Amazon, in person, your Mother…all of these together, in

combination, in sequence:

It doesn’t matter how – the result is You Have A Unique Key, Known

Only To You and the QT™ QDS



Note: There are two distinct classes of interloper: active and silent. The active interloper, who we have covered already in the Intro paper; they can be you, but you’ll be alerted, and they have to be you again in the real system, not just this public QT™ security channel, and they can’t go backwards for anything you’ve already done. The straightforward solution is to just perform another VSU. AND/OR – if it’s a real system that is using a private QwyitTalk™ service as the authentication token, then there would always be a you-to-your-key 7-digit hex PIN (minimally, everyone/anyone can remember 7-values, like a phone number) that is never stored. This interloper’s capabilities are known, minimized and solved. If the majority believe it’s a good idea to implement PINs, then we’ll put them in the Public QwyitTalk™. Silent interloper: The listener, who knows every communication, from any source, at all times; except, of course, the in-person (Spy-like) key delivery methods: in person meets, drops, etc. (espionage!) Without too much difficulty, even this interloper can be defeated:

QwyitTalk™ is an underdetermined system: simply add an unknown. Since there isn’t any unbreakable way to extend an unknown* in order to force The Listener to have to ‘do more work’ than already exists in the system; in order to thwart every attack and return the unbreakable entropy, one simply/must add a new key. Make the key as large as the work you want the listener to perform – if it’s forever, make it that current length (at publication: 256-bits). *There is a way to expand unknown work – such as having an n-digit unknown that points into a z-digit unknown number vault, ‘delivering’ unique results every use. This doesn’t expand the ‘work’ of delivering an out-of-band unknown single key, but does expand the work of figuring it out: deliver a lot, point into it, work expands!

If you add a 256-bit key outside of QwyitTalk™ (un-listened), then you can use the Public System. Of course, as just noted, a private QwyitTalk™ will subvert The Listener – but if you want to keep your messaging unbreakable even to The Listener w/any particular public recipient, share another secret – sized appropriately to your particular requirements – outside the Public QwyitTalk™ system, and then you can still use it. As there is controversy whether or not government agencies put ‘back doors’ into crypto products, it’s simple to put in a ‘front door’ allowing anyone using the Public QwyitTalk™ system to input ‘An Outside Key’ into the formulation of every QTQS message. If implemented and used, it will thwart all The Listeners. The war ends at Unbreakable. Privacy wins.

On to the AH per-message key delivery and cipher unbreakable: Per Message Token/Credential Distribution (Authentication Handshake – AH) and Messaging (QwyitTalk™Cipher) The QT™ AH messages only include an encrypted SSK – there is no context for any decryption to result in positive knowledge of any PT. This is unbreakable; every PT is possible for every/any CT. The only question remaining about the QT™ cryptosystem is whether the messaging ciphertexts between two participants, after receipt of their SSK, meet the unbreakable standard of an OTP:



The Qwyit™ Cipher In either direction of The Qwyit™ Cipher, to create a single Child Key (W) for operation on a unique 256-bit Plaintext/Ciphertext there are:

FOUR (4) equations o MOD16, Combine (which is a Mod16), Extract (a pointer selection), and XOR (or MOD16)

SIX (6) unknowns o MEK, R, MQK, A, W, PT

For each next-Child Key, for operation on the next unique 256-bit PT/CT, there are:

FOUR (4) equations o MOD16, Combine (which is a Mod16), Extract (a pointer selection), and XOR (or MOD16)

SEVEN (7) unknowns o W, R, NextR, MQK, A, NextW, PT

Even a broken W resulting in a Known Plaintext attack doesn’t provide any knowledge on going forward (as the system looks identical as it did at the start: 4 equations, 6 unknowns (the next PT)). Nor does it help in going backward, as one only has knowledge of two of the unknowns (W and PT), but only one equation is solved (the XOR). Retracing to the three equations that led to the XOR, one is left with 4 unknowns (R, NextR or MEK [depending on whether it’s the first 256-bits or any succeeding 256-bits], MQK, and A) and 3 equations (MOD16, Combine and Extract). The Qwyit™ cipher is unsolvable in either direction – even with a broken Message Key. (The one thing a true OTP doesn’t really include are CPA attacks – OTPs are instantly useless if you know the PT. QT™ has accommodated this ‘vulnerability’ with its key distribution/key creation method, rendering known PT a dead-end ‘break’. Unsolvable is Unbreakable. For examples, and if you’re not convinced, work through the following Challenges. Part III – The QwyitTalk™ Challenges The following are four ‘challenges’ that provide empirical evidence of the unbreakable properties of QwyitTalk™: Challenge1

The DSK updates provide mathematically separate new random versions of the starting, Authentication key (in two parts, MQK, MEK) using the feature of Random Rearrangement provided by the Qwyit™ primitive, PDAF



Challenge2

Multiple different DSKs will deliver identical Ciphertext from the same Plaintext and OR salt even through a chain of unique Message Keys – the ciphertexts are all unique

Challenge3

Multiple different DSKs will deliver identical Ciphertext from different Plaintexts yet same OR salt – the ciphertext is all identical o This is true for a chain of unique Message Keys (although not shown due to the ever-increasing combinatorial

possibilities, even with 4-digit keys) Challenge4

A DSK to SSK to SMK message test with current 512-bit DSK/SSK – What are the key and plaintext results? For all Challenges, in order to print ciphertext in this paper, all ciphertext is twice the length of the XOR byte result, where 2 hex chars (each representing the Hi/Low 4-bits of a single byte) combine to be each byte of ciphertext. Example: 6D represents the ASCII byte “m”. Again, in summary, QwyitTalk™ is unbreakable because:

The cryptosystem can deliver unique DSKs that result in the same ciphertext (Challenges 1 and 2)

The Message Keys are true OTPs, delivering identical ciphertext with indistinguishable plaintext possibilities (Challenge 3)

Challenge 4 can’t be broken mathematically o Guessing, PRNG breaks, etc. – anything less than presenting a method for delivering the keys and PT doesn’t apply



QwyitTalk™ Challenge #1 – Separate, Unique DSKs

The above is a screen capture of a small program written to perform 1M PDAF Random Rearrangements (RR); starting with PRNG random keys, and ending with random keys. 1M ‘ephemeral’ key updates in this manner (or double-length extension along with an OWC) provides a truly one-way gate; and have a long-lasting system capability, limiting the number of times a new key VSU delivery is ‘required’.



Challenge1: Demonstrate, show, prove

A PDAF is not a one-way gate – that one can find the starting keys in less space than brute force from a known result o Be sure to familiarize yourself with the full capability of the PDAF function – starting offsets, pointing modes, cycle numbers,

skip values, etc. Whatever ‘less’ than brute force may exist can more than likely be recovered o Be certain to include discovery of any reduction in strength in terms of the doubling+OWC option

A key that passes random ‘qualification’ (however defined) is any less random after n PDAF RRs o And how such a ‘loss’ results in a system vulnerability (since the upper level keys never encrypt anything but other keys)

Any other issues w/the PDAF primitive (and in combination w/an OWC) for RR new, next use (as an OTP)



QwyitTalk™ Challenge #2 – Identical unique CT, Same PT

The above screen capture is from a small program written to encrypt the exact same PT (“I’m smarter than you” – sorry, that’s tongue-in-cheek!) and the same OR (“7AACF9”). This shows that multiple different DSKs will deliver identical Ciphertext from the same Plaintext and OR salt even through a chain of unique Message Keys (in the above, the 6-digit W’s are used in 4 re-configurations (using NextR) over the 20-digit PT) – and that the ciphertexts are all unique. This is the same as not ever being sure what Pad encrypted ‘Attack at dawn’, as the PT is the same, but the CT would be different.



You’ll notice I used small, 6-digit hex keys so that you can easily verify these results yourself – they were encrypted using the Qwyit™ cipher substituting a PDAF/OWC combination for the Combine/Extract (since the C/E function is more ‘complex’ in code when the key length is shorter than the key base; and I simply didn’t want to write that, since I already had the PDAF ‘going around the edges’). You’ll also notice that, because of the smaller-than-base length keys, some of the key pairs are almost identical (ex.: 11CC90/AB55A8 and AACC92/AB55AA only having 1 digit different in each pair), and some are quite different. You won’t find that the case once the key-length is longer than the base, as the Qwyit primitives will deliver all possible results when the matrices are full (i.e., when all of the selection slots have values). Challenge2: Demonstrate, show, prove

That although these are obvious, empirical examples of the underdetermined property of the Qwyit™ key processing, they are somehow solvable such that you could determine which key pair was correct (not just valid).

That somehow, using proper, current key lengths (256-bits at publication) will result in ‘easy’ determination of a valid key pair o Some knowledgeable and motivated person may well want to present the combinatorial probabilities of the varying valid

key space – in relation to the starting space and in relation to the work required to find the first one o Also determining a way to present how many NextR iterations any type/configuration of the starting DSKs any particular

valid set will contain/provide. The above small example has 11 key pairs appearing out of 100K random starting DSKs (where there’s 1612 possible combinations) resulting through 4 iterations. How many would last more, how many less?

IF you went to all of this work – one can only apply it to Known PT – see the next Challenge as to why

And…what does Known PT get you in Qwyit™? (Nothing, we’re pretty sure…)



QwyitTalk™ Challenge #3 – Identical same CT, Different PT

The above screen capture is from a small program written to encrypt two different PTs (“Paul” and “Saul”) using the same OR (“631F”) and resulting in different DSKs creating the exact same CT (this is the “Attack at Dawn” vs “Attack at Dusk” classic OTP dilemma). Multiple different DSKs will deliver identical Ciphertext from different Plaintexts using the same OR salt – and the ciphertext is all identical. In case you’re wondering why there are the same key pairs listed multiple times (it says it found 10, but there’s really only 4), it’s because the easiest way to test this is to fix one PT/CT/OR result, and scan the other for matches – and I just didn’t bother to put in



code to check the result against any I’d already found (too slow, going through both sides) I also left that in there to make a point: there are 164 possible CTs for each PT – but there are 168 possible DSKs making them – and from the last challenge, these will result in different CT for the same PT on each side. I only captured one CT from one side, testing against only 100K random tests dipping into the 168 possibilities from the other side (of which there are only 164 unique results, but those are also duplicated)…SO: how many times does this happen across all those combinations? Enough to be Unbreakable. The accurate combinatorial possibilities can be described. Challenge: Demonstrate, show, prove

That although these are obvious, empirical examples of the underdetermined property of the Qwyit™ key processing, they are somehow solvable

Somehow show that this is a problem – even though it matches the exact OTP classical proof



QwyitTalk™ Challenge #4 – A Message Test A DSK to SSK to SMK message test with current 512-bit DSK/SSK – What are the key and plaintext results? Here is the complete output: (Created from the QDS-Full-Example.exe QT™ Reference Program, available from Qwyit LLC) During the AH, in order for Client1 to securely communicate with Client2, in response to Client1’s AHC1 request, the QwyitTalk™ Security as a Service QDS sends this AHQ3 message to Client 1, and then Client1-to-Client2 messaging ensues:

All QT™ missing keys and PT shown redacted (3333) o The message traffic that would be sent openly is highlighted green, the commenting is informationally provided to explain

the processing, as performed by the QDS and QT™ clients



QDS Now, I'll send out the AHQ3 to just Client1 with Client2's wrapped SSK

I need to get an OpenReturn in order to encrypt the AHQ3 for Client1

OpenReturn = 7F14FCCF88D221A6C6BE5CC4922722339644F0B75D19262AD324CA6ED712276A

Click Continue in Client1...

Only AHQ3 is to Client1...

The AHQ3 Client1 message key is 3C00F45845B345F679966D4E876540F324C883F9448670984F56169283C4F044

The AHQ3 first ciphertext is

71750104040C710B03027770077676720F0801727406030779050270040075060B0471090F77717B0D777E0607020F7A02730C0E09010802

087172757774070C02020006030C070D77017B7104760402077D01770170707C0971000305727E770075767C010A720F06770C0F0E030B7D

0504747307077F77080B747707030177

The AHQ3 Client2 message key is F4F09E8F018BE148C35F84F12C41A42D38EFF3BC5DF8A49C8AD40C70BF8EF20C

The AHQ3 second ciphertext is

040277047B7D7C7507060D017672047C7B020D027A76717373710074710401710A087777717775010C07000871060F010E747D0C0874060

0720409047776037B777576067C7D0A73730501007572760C73770D070F0002080305020770760A00017970027F0A76750707720178070B0

60903057106727175727E0F0607010500

[AHQ3: 0123456789ABCDEF, 7F14FCCF88D221A6C6BE5CC4922722339644F0B75D19262AD324CA6ED712276A,

71750104040C710B03027770077676720F0801727406030779050270040075060B0471090F77717B0D777E0607020F7A02730C0E09010802

087172757774070C02020006030C070D77017B7104760402077D01770170707C0971000305727E770075767C010A720F06770C0F0E030B7D

0504747307077F77080B747707030177,040277047B7D7C7507060D017672047C7B020D027A76717373710074710401710A0877777177750

10C07000871060F010E747D0C08740600720409047776037B777576067C7D0A73730501007572760C73770D070F0002080305020770760A0

0017970027F0A76750707720178070B060903057106727175727E0F0607010500] sent using Port 4180 to Client1

AHQ3 processing now switches to Client1 and Client2




Client1 Now I am going to talk to Client2 in our application...

First, I'll create a Qwyit Return (QR) value

QR is

DFEB16125CF4510FCC5091500D312F93773EF72D2AFFFE9AC3B40A5FC2AAEA04F7861E1E250E31337E6DACD7E9FEA5A0E974613DB8B10E2

32B0C6C03CFBF75AE


Next, I'll use the SSK from the QDS and the just created QR to create a Session Master Key (SMK, in 2 halves, SQK and SEK)

New Client1-Client2 SQK is 85FFCEE5C3408D0C4DDD4CCBAF7F2FC8075F6498B6EFF0F5284C816FCDB4F73C

New Client1-Client2 SEK is 018CF633E9993DE77BE710A0F854B02D03C1FA73D4FA914136AACDF1C72B18FA


Now ready the message, which will be: 6k0vxhW_JVi6uWqRMihoyFNWvhlzXNmSgR99pD5_hITBF3yrqgFfS0eo219swmFu

Then, encrypt it using QwyitTalk...

OpenReturn for this message is B57BB6519D3077EC0A11B38AB3198183AF7E981AC9B3A87589D345E60CB9F8B1

The QTQS message key is D9E211F41000429C82718AF0726B31DF1E80C7B8CA09F1AB373B8F6B09835109

QwyitTalk Qwyit Start (QTQS) is

0123456789ABCDEF,

DFEB16125CF4510FCC5091500D312F93773EF72D2AFFFE9AC3B40A5FC2AAEA04F7861E1E250E31337E6DACD7E9FEA5A0E974613DB8B10E2

32B0C6C03CFBF75AE, B57BB6519D3077EC0A11B38AB3198183AF7E981AC9B3A87589D345E60CB9F8B1,

7F14FCCF88D221A6C6BE5CC4922722339644F0B75D19262AD324CA6ED712276A,040277047B7D7C7507060D017672047C7B020D027A7671

7373710074710401710A087777717775010C07000871060F010E747D0C08740600720409047776037B777576067C7D0A7373050100757276

0C73770D070F0002080305020770760A00017970027F0A76750707720178070B060903057106727175727E0F0607010500,72527544495911

6B7B66590641654811755B5F5E41070867415A5A386B7F291556170109337377672B08647B00023830425075246B76532D02080140425C76

4C

Now, QT processing continues in Client 2...




Client2 I've just received a QTQS message from Client1...I'll process it!

First, I need to unwrap the SSK...

The Client2 AHQ3 received message key is: F4F09E8F018BE148C35F84F12C41A42D38EFF3BC5DF8A49C8AD40C70BF8EF20C

The Client2 AHQ3 received plaintext, which is the SSK, is:

B614B8D3775C3C0D818DBB7BA24E003590217D7B9CF0026B659887100B1A1D381A06E825C49B0CB40D8A74D91F661B8D2A5D99462C499

32E1BAE61FE087CA35C

Next, I need to unwrap the SMK...

Now, take the just received QR and create the SMK for this message

New Client1-Client2 SQK is 85FFCEE5C3408D0C4DDD4CCBAF7F2FC8075F6498B6EFF0F5284C816FCDB4F73C

New Client1-Client2 SEK is 018CF633E9993DE77BE710A0F854B02D03C1FA73D4FA914136AACDF1C72B18FA


The QTQS message key is D9E211F41000429C82718AF0726B31DF1E80C7B8CA09F1AB373B8F6B09835109

QTQS plaintext message is 6k0vxhW_JVi6uWqRMihoyFNWvhlzXNmSgR99pD5_hITBF3yrqgFfS0eo219swmFu

Now I'll reply back to Client1...message is: seSC7IpxZVGq6hRqKhbchHf0mJXdpD_QDlcGsVXGBdWJynOve8b.hmCZnwoiMChp


OpenReturn for this message is 6843989379FC5A8E7AB710F95D6D0B3723ACEBB3F0F0BBDE367008D45E2F9644

The QTQT message key is C9D694E21E2CC69BD694D5623ED049C793DE092DB70A79704DF2D7D021DD81EF

QwyitTalk Qwyit Talk (QTQT) is CBEC3BF4B47CA8B0, 6843989379FC5A8E7AB710F95D6D0B3723ACEBB3F0F0BBDE367008D45E2F9644,

305C17750E7D354A6B137532755E6B330F5E5B572C7D50025E0F1C54447D1C667D5F2702436F6A030053670B4E577846517C241C2C5A076

A5C462B2D75722D36

Now, QT processing continues in Client 1...




Client1 I've just received a QTQT message from Client2...I'll process it using our shared SMK keys and the sent Open Return!

The QTQT message key is C9D694E21E2CC69BD694D5623ED049C793DE092DB70A79704DF2D7D021DD81EF

QTQT plaintext message from Client 2 is seSC7IpxZVGq6hRqKhbchHf0mJXdpD_QDlcGsVXGBdWJynOve8b.hmCZnwoiMChp


After sending and receiving and the SMK key life is reached, both Clients perform a PDAF PFS ephemeral DSK key update

This is accomplished using the SQK and SEK in a PDAF. Optionally, for a 1,024-bit length, and then performing an OWC to pare to 512-bits

First, here in Client 1...


Here is the PDAF result for Client1 new SQK/SEK keys:

D4F30625708CCCF7EC4C0835547FDB387BA3E687159555BDA4BFD04CA2292530717C8BED670C5FC6392FF71A0EE6871750787CE7AB2EE27

935787DBAACE0BCFC73CC8E62BF0B5C8BB5CCE6B285C40FBDFFD7C8B878DBB80183047F231C77737443FC7AB53FFA59033D393B2A936E1

62A629A50178E5CC45D1CC14F9E89384A096AB362E1BEEFC57B6415B30D98D514004D152CDD6A1AACE6E79B66A6FB04EB0C613BBBA9ED

374D5E326D3B5AA7B32E5C95DD355AF2A338BBFF3B6D620BACE708D8CB3B22B2BF44FB0C546E479A081544866E1A10AE6EE1C4DB38D4E

BC2A1BF7049CABBB28A323268C3823B73F5F77370B6BEA3AC273666A1640A45374974D4F9

Here is OWC final result for Client1 new SQK key: 12677486A088968B2D4F6EA8EAD0CB73833BDC42C16BE4F85F3550008F456E7B

Here is OWC final result for Client1 new SEK key: 57E4DA8AC94B3868E4B184F08B19EBA7D66D255EFAEA46A719D699CBAA9ADB18 NOTE: That second key looks like it has more letters in it than numbers…OOOOHHH NOOOOO!!!!...leaking entropy…

Now, update the SMK in Client 2...




Client2

Here is the PDAF result for Client2 new SQK/SEK keys:

D4F30625708CCCF7EC4C0835547FDB387BA3E687159555BDA4BFD04CA2292530717C8BED670C5FC6392FF71A0EE6871750787CE7AB2EE27

935787DBAACE0BCFC73CC8E62BF0B5C8BB5CCE6B285C40FBDFFD7C8B878DBB80183047F231C77737443FC7AB53FFA59033D393B2A936E1

62A629A50178E5CC45D1CC14F9E89384A096AB362E1BEEFC57B6415B30D98D514004D152CDD6A1AACE6E79B66A6FB04EB0C613BBBA9ED

374D5E326D3B5AA7B32E5C95DD355AF2A338BBFF3B6D620BACE708D8CB3B22B2BF44FB0C546E479A081544866E1A10AE6EE1C4DB38D4E

BC2A1BF7049CABBB28A323268C3823B73F5F77370B6BEA3AC273666A1640A45374974D4F9

Here is OWC final result for Client2 new SQK key: 12677486A088968B2D4F6EA8EAD0CB73833BDC42C16BE4F85F3550008F456E7B

Here is OWC final result for Client2 new SEK key: 57E4DA8AC94B3868E4B184F08B19EBA7D66D255EFAEA46A719D699CBAA9ADB18


This concludes the AH and QwyitTalk demonstration. Thank you!

Client1 This concludes the AH and QwyitTalk demonstration. Thank you!

THIS COMPLETES CHALLENGE #4 Challenge: Demonstrate, show, prove

The Answer – keys and PT

Provide rational response to the real question: Whether or not you agree with us on the full capabilities of QT™, it’s not trivial, the performance is unquestionably superior (see 2015 NIST Lightweight Cryptography benchmark submission), and its potential is substantial – and it is unbreakable… why on earth aren’t you using it somehow/somewhere?



Afterward We think it’s important, just as a recap, to state that, unequivocally, there are absolutely no new cryptographic ‘processes’ in QwyitTalk™ that haven’t been invented; and, of course, that’s the whole point: QT™ works just like all of the well-known, well-defined, well-researched, well-thought out, well-attacked crypto best-practices:

QwyitTalk™ Security as a Service is TLS

The Qwyit™ Cipher works just like any other block/stream cipher o Random IV (OR) o Key mixing to derive child keys o Child keys perform quick-step encryption (XOR, etc.) o Embedded authentication (called Additional Authenticated Data (AAD) and other terms)

The result is something quite different, though, than the inputs: QT™ is unbreakable. References www.qwyit.com All of the pertinent papers are available there – and references are included. Epilogue We’d like to mention all of the real cryptographers that helped us make QT™ the complete system it is today: Dr. Alan Sherman, UMBC, whose early critique forced us to complete the full protocol, matching the system’s properties to our claims Dr. Hatsukazu Tanaka, Kobe Institute of Computing, whose acceptance and promotion of our work was given its highest praise by including it in his own – extending his research on key expansion and ciphers Dr. Giovanni Di Crescenzo, NYU Tandon School of Engineering, whose full, in-depth independent reviews – and NIST submission/work – and constant questioning of our work, led us here – completion

All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed.

Third, it is accepted as being self-evident. - Arthur Schopenhauer

http://www.qwyit.com/



Appendix A – A Bit More

Notes from the Author While working on this discussion, I included a few tangential pertinent points – here they are:

The breadth of unbreakable Alan Lightman, from his review of Exact Thinking in Demented Times: “When I was a physics graduate student, I was introduced to the philosophical ideas of Thomas Kuhn and Karl

Popper. (Regrettably, such books are not often taught in the education of a science student.) Kuhn in his landmark

“The Structure of Scientific Revolutions” (1962), suggested that major advances in science do not result from

small, incremental steps but instead from sudden and occasional sea changes, “paradigm shifts,” in which a

completely new view is proposed and finally accepted by the community of scientists, often a younger generation

who must shove aside the old farts or wait until they die.”

The New Carbon Architecture, Bruce King: “This could have been a much bigger book. It might have been a 400 page tome fully reporting the state of the

art with tables, graphs and other hallmarks of good science, or it could have been shaped as an academic

textbook. But it seemed better to get the idea out into the world, as simply and readably as possible.”

Blaise Pascal – loose translation from his French – courtesy of Lloyd Alter, Treehugger Editor in Chief:

“I'm sorry I wrote you such a long letter; I didn't have time to write a short one.”

This document is something quite different from the current thinking in cryptography, it could have included a great deal more ‘formal’ information making it even longer…and yet it is long enough to slow most of the instant dismissal that would occur w/a short version. If I can ask for your indulgence, please critique the protocol; not me.

The Science Is True I read in some article, that someone asked Neil DeGrasse Tyson how to reconcile the belief in God/Creationism versus the belief in The Science of Evolution; and he said (something to this effect – which, if I have it wrong, he should have said it like this; it’s quite concise and perfect): ‘It doesn’t matter what you believe, The Science Is True.’* This, to me, means that all of the discussion after the fact of unbreakable, is meaningless. A system where all messages are secured by an unbreakable cryptosystem is perfect. That science is true.

[*His actual quote: “The good thing about science is that it's true whether or not you believe in it.” ― Neil deGrasse Tyson]

https://www.ecobuildnetwork.org/projects/new-carbon-architecture



Theory versus Math The ancient Babylonians (or the ancient Egyptians) ‘discovered’ and defined Pi in 2000 BC. Ever since, in order to use it, one had to calculate all the digits, because there was no way to know the nth digit without calculating the ones before it. Experts attempted solutions for almost 4,000 years! Oops – until 1995. There was a formula, it just wasn’t known. Because Pi, while only a mathematic constant, has many ‘magical’ properties – it’s like theory, where things are discovered all the time. Placing trust in theoretical cryptographic applications that don’t yet have solutions is a bit short-sighted. There are over 20,000+ advanced mathematicians working at the NSA. And there’s China…and…you get the picture: Theory isn’t a good place to leave a secret: Remember The nth Digit of Pi!!!

Forgive Me For I Know Not What I do “Dumbledore says people find it far easier to forgive others for being wrong than being right.” – J. K. Rowling IF someone figures out a way to break the Challenge, it’s because I just made a mistake, or left something out. But, the QT™ Primitives can be arranged to provide unbreakable. Of this, I am positive.

The Lesson Have you seen that YouTube video of the crazy guy who puts his finger into a circular saw blade….AND IT STOPS?! That Guy Is The World’s Greatest Entrepreneur! Talk about believing in your product! That guy’s product is called SawStop®. They figured out a way to stop a rotating circular saw blade instantly so it won’t hurt you. Some 55 thousand+ injuries happen every year. So – they take it around – attempting to monetize their revolutionary idea. ‘Amazingly’, No One Cares. So they build their own products; which can’t really compete with the Status Quo. Now, several years later, Bosch (a Status Quo stalwart) – they release a saw with the same capability! No, they didn’t pay SawStop a licensing fee from their patent; Bosch changed it ‘some’, and received their own patent. They are all now in litigation. QwyitTalk™ is unbreakable. If someone else builds a different unbreakable – great. Use that. Whatever happens to QT™ isn’t up to us anymore…it’s up to all of you. Will you make QT™ unbreakable the new Status Quo? Or will the Status Quo make a new unbreakable?

Epilog 2

To my old, dear friend, Glenn Veach. May you rest in peace…knowing I finally had the courage to tell everyone what you kept trying to tell them for me: There is a God…and it is Truth.

Thanks Darrell…you were the first to believe in me. Michelle…more than faith. Ken…who put his money where my mouth was. Jack…if anyone I know needs to find a reason, I’ll tell them to come see you. Greg…who invested in us because of Glenn’s devotion…Taylor, my son…Thank you for trying. Oh…and Mike. He’s still right here…21 years later: That’s something more than everything.

isn’t qwyittalk™ unbreakable?qwyit.com/assets/files/qwyittalk-unbreakable-v1.2-with...qwyit llc...

Documents