Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mirandify OpenSource #214

Open
MostAwesomeDude opened this issue Apr 21, 2020 · 2 comments
Open

Mirandify OpenSource #214

MostAwesomeDude opened this issue Apr 21, 2020 · 2 comments

Comments

@MostAwesomeDude
Copy link
Contributor

E's original auditor proposal suggests an auditor, OpenSource, which allows objects to open their AST for inspection on an opt-in basis. But what if we made it opt-out instead?

Let's have a Miranda method which exposes the AST of the current object, or null if not interested in sharing source. Reasons for opting out include being a native object, being a powerful object, being a puzzle between agents which relies on hidden source (think guess-the-number puzzles), etc.

@dckc
Copy link
Member

dckc commented Apr 21, 2020

... Reasons for opting out include ... being a powerful object ...

That doesn't seem fail-safe. Am I confused?

@MostAwesomeDude
Copy link
Contributor Author

Trying to remember my thoughts here. I don't understand why, in the original E auditor proposal, it isn't just automatically the case that every auditable object is OpenSource. Kerchkoff's principle implies that an object isn't powerful on its own; its parameters are what make it powerful. But cryptographic key material could be inlined into an object's AST as a literal. So there's some sorts of powers which might be perfectly well-representable but which the object might want to avoid representing.

But that's not quite the whole story, because there's computability arguments that we can't tell the difference between plain numbers and cryptographically-relevant numbers. So keys will always need some sort of human-readable annotations and guardrails which prevent them from being too easily misused, even though we know that they will promptly be misused. We already do this in Typhon's runtime bindings for libsodium; when we generate keypairs, we wrap them to prevent the bytes being shown too easily, and there's a switch for logging every time a key is revealed.

This is all aside from native objects, which simply might not have a portable or non-circular representation in Kernel-Monte. _makeList comes to mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants