Rapid return from dead

There are two ideas here - how to construct a sharable model without a zero-knowledge-proof such that the receiver gains nothing from working on your model and how to construct a revenue stream from a single sale product. These generic iseas are applied to my efforts.

Two new method of software construction and sale
Non-cloud sold software as a service

Aaquantum-co-opt- Two new method of software construction and sale

Sometime, an expansive small core can underlie a large number of applications such that the core is required essentially in all applications. Typical example of essential core is solution to NP-Complete problem. In these cases, a simulation of some applications can be built using copy-left software; all except the essential core.

The essential core is simulated by a table lookup. The entire simulation can now be safely sent to investors, alpha users, market specialist, venture capitalist etc. It proves

1.       The progress already made

2.       Safety from competition

3.       Applicability to consumer uses

4.       Time and cost estimates on remaining work

5.       Parallelism possible in rapid deployment

6.       What the investors bid on

7.       Essentiality in the applications considered

It is separate from the selling documents attached to the application. The final product is the development of all the non-essential components given for free, without limitations. A bounded, but functional essential core is also so available. No one can question a proprietary component to duplicate a slow part in component pipeline.

The essential defeat of copy-left for some applications by doing some parts open, some closed; obeys these cardinal rule of software from Natural Justice

1.       Thou shall never call code written by others your own

2.       Thou shall never interfere in viral growth of free software

3.     Thou shall never assert software-patents

Selling is accomplished by including the complete package with extra optimized component.

The second essential method is never sell the essential component but provide its results as a remote software service black box which accepts an encrypted message and returns an encrypted answer, perhaps using own values from previous transactions as well.

An application

Rather than NP-complete, provably hard encryption problem is used – square-root of 1000+ bit  integer field. For simplicity it will be called dsqrt. Also useful are dmul, ddiv and dexp all modulo some M, ^ is exponentiation., % is mod. Most cryptography magic arises from remainder operation, % in C

Cryption

                Put(message, key, sender-edata, public-receiver-edata => fail | e-message, p-key, p_data) -- all published,  public-receiver-edata has M

                Get(e-message, dsqrt(p-key,M), p-data, receiver-edata, known-database-edata => fail |

message, who, when, serial, …)

                Note that

p-key = (key*key)%M

                And dsqrt(x,M) = (ask_me(p-key^public%M))^private%M

I know not public or private, user finds the dsqrt since dsqrt and ^ commute! I simply calculate the dsqrt of some number sent to me! I and consumer need each other – only customer knows the public, only I know semiprime roots!, not sender, not receiver.

Clouds are considered union of sub-cloud. There is one or more me in every sub-cloud. Any consumer can select sub-clouds for enabling ask-me. Regardless of connectivity loss, as long as one sub-cloud works, ask_me works.

Critical is me as an essential service, whose rates can be set by marketing and advertizing concerns, leading even to provide the whole chain as a product. Additional to work here is conversion of any software product as periodic (annual or monthly) service.

Elimination of Man-in-the-middle

It is assumed that digesting is a secure operation. How then one ensure a and b are related. Assume that digest are half bitwidth of encryption. Then (known1^cpower%me) = digest(a) // digest(b)  && (known2^cpower%me) = digest(b) // digest(a)  where // indicates bit concatenation, implies that a, b are related. Reason is that there is no effective way of forcing digest on right and left implies that right has the known decryption.

Register

To setup an account in family f, consumer does

Register(family, f_permit,name => who,known1,known2,public,private) -- After register, only factors of who kept.

After getting f_permit from the family admin. After testing once, who of a name is known. Then encrypted messages are sent. One can set up records for a name in tables and use the digest of the block, rather than who, make who a field of the record, thus extend binary to secure n-ary relation.

A new family is created by fregister.

fregister ( long_family_name => family, permit_base)

f_permit(name) = permit_base ^ digest(name)

Secure broadcast

The message can be encrypted once. So is p_data. They are published once on a cloud. The key is squared once for any recipient in consumer who to p_key. To read, the recipient gets the dsqrt from me. Uses that to decrypt e_message and e_data.

Secure message

To guard against malicious cloud modification, the sender can pass the square of the digest of message. That can also be dsqrt and checked.

Relevance to class-of-75, other friends and me

In order to ensure freedom from bugs most of software must be open source. But that makes software hard to get revenue from. Also socialist FSF, with its copy-left, has collided with other less restrictive open sources. Ideal situation is mine who claims knowledge of a very hard problem, whose answers can be checked easily on every use and whose veracity can be checked by testing, even by adaptive dsqrt. Further most of the program is open source. Open or closed source replacements are possible provided that the extender disclaims any software patent actions.

With this in mind, family, class-of-75, other friends, investors, venture capitalists and journalists can peruse to answer

1.       Feasibility of making money

2.       How much has already been done

3.       Competition and uniqueness

4.       Difficulty in compete by this method

5.       Difficulty in compete by another method

6.       Lack of disadvantages by open source

--------------------------------------------------------------------

Aaquantum-co-opt- Non-cloud sold software as a service

Sometimes, one is interested in viewing software products as periodic service, where people buy the latest edition as a service, and the old version develops a flaw, the certificates issued by the old software are not valid. This entire work depends on the principle that a semi-prime is crypt-useful only if its factors are secret. If the owner of the semi-prime discloses the factors, all crypt-certificates lose their certificate character! It is a dumb idea to do it for messages sent by someone. However, it is perfectly sane to do it for defeat of the man-in-the-middle!

You want to duplicate Microsoft windows for protecting revenue!

While none of the old messages become reusable, the certificate of genuineness of the mail owner public is at stake! An ordinary criminal can criminalize new customers of the buyer. The buyer has no sane option but to buy a new identity certificate! Note that the identity certificate semi-prime idsp has nothing to do with communication semi-prime of the buyer! If I use it to certify identities every year, then disclosing its factors end every year means

1.       All previous identity certificates are lost

2.       No communication of anyone is disclosed.

3.       Existing customers can reuse the semi-prime as before. However, while criminals cannot spy on mail, they can build fake confusing identity certificates and destroy some mail, while launch some sophisticated adaptive attacks. In short the critical principle of mine is lost – never trust anything, even repeated, without a certificate. But this principle, or another reason, gives me clever resale method!

Use of these ideas

                Use in my secure email system is easy.

Put( target, key, sender_full, Target-public, Certificate => emessage, ekey, letter-cert)

Get( allowed{sender}, emessage, ekey, letter-cert, receiver_full => message, …)

Trust in sender and letter requires certified identity!

Kill spam

                My method provides a technological solution to the worldwide problem of spam! Note that the Get is not from anyone but from a whitelist! The list is in consumer control! It may consist of names or recommended_by names. If the sender is not in the whitelist, letter goes to wastelist! Initial whitelist will include on-government-service and essential-services (police, medical, emergency etc.). The list can be dynamically expanded or contracted. A republican certificate may allow republican candidates, authorized to send mail. A consumer might add democrat, republican, libertarian etc. Point is

1.       Allowed list may permit not just individuals but idea keepers.

2.       Allowed ideas may or may not be static. People conforming (even incorrect fine, the allowed cut) after 1 or 2 errors) allowed even not known.

3.       Not just political but advertisement as well! Generally some companies allowed if selling wanted. To some extent, consumer directed advertisement!

4.       Perhaps user allows movie stars, sports stars, typical consumer, religious, business or political stars. Everyone is allowed to be stupid.

5.       Consumers are allowed to lie on anything, including by  convincing-lie software. Change whitelist dynamically. Prevent id detection. So much for incentivized surveys.

6.       Membership in any list requires a certificate! Days of honest SPAM are over! Today’s spammer lies about who sent and why sent!

Use in class-of-75

Above is just a label, to which some subscribers send letters. Essential proposed difference is trust! At this moment, no one can truest the sender, only possible in cryptographic transparent scene. Use of my cryptography, when done, in billion odd groups is intended to be transparent. Instead of submitting your jewel to current email, you submit it to aaquantum-email, also used for transcripts of allowed senders. Unlike email, and more like Facebook, you would have, you settable, event generators. Those specified by at least  1 class-of-75 other than yourself will be sent, via class-of-75 to the interested and inserted, according to policy, at once, or delayed into the transcript.

Messages have a subject, imp0licitly if replied to, explicitly if named. On consumer list of allowed links to messages in store computer for class-of-75 (perhaps replicated) will be kept per consumer. Simple primitives will exist to move messages to consumers. There is no need to repeat messages again, rather than link to set of links for that subject.

All messages will have a one line summary, displayed in the transcript along with a link to the body.  Complete line looks

<reasonable-reco> <who> <subject> <line …> <detail-link>

$rea above is needed to allow a designed reader by consumer to certify that the summary is indeed a fair summary, not a moronic headline! $who is the writer. $sub is about. $dea is link to real mail. 

Apart from <like> and <dislike>, there will be <n-like> and <n-dislike>, Also a link to conversations.

Class-of-75 is as if a virtual person, with Facebook like interface!

Why confident of win

There are exactly two ways to win trust – long trustable history, or provable can’t hack i.e. cryptography. EVERY ONE hackable WILL be hacked and that means ALL members of class-of-75.,

specially as unhackables increase and criminals become desperate! I hope all bless me in this confluence of fighting old age and block-medium. Regardless of philosophical belief, 2020 onwards, earth belongs to the unhackables!