de·code
dēˈkōd/
verb

  1. 1.
    convert (a coded message) into intelligible language.

Unintelligible ciphertext -> DSE -> Intelligible information than can be conveyed as language.

It pretty clearly does.
Let me clarify: DSE does not decode in the traditional sense. A cipher targeted by DSE is not broken. DSE looks at text and asks "is there information being conveyed in this text?" If the answer is "yes", DSE makes the original text, sans anything hiding, obscuring, or encoding it, clear to the Solar.
How? Fucking magic.
 
But then all you get from a one-time pad - is the text of the one-time pad.
Because that's all the information that is in it AND all the information that is being conveyed.
Just like a message of "open book XYZ at page 11, take third paragraph, second word, fourth letter. Repeat for QWERTY etc.". All it does is contain a set of instructions. You get those, but they're absolutely useless unless you have books in question. A one-time pad is just like that.
 
Let me clarify: DSE does not decode in the traditional sense. A cipher targeted by DSE is not broken.
Uhh...yes it is(at least, assuming that it can). If you have both the coded message and the decoded text then even if you don't have the exact mechanics of the cipher at the moment, creating those is trivial.

Also, you still have addressed the issue of if this is a valid use of the charm, then can a Solar look at a message that says "Execute Plan B" and know all the details of plan B? And if not, explain the difference.
 
Just like a message of "open book XYZ at page 11, take third paragraph, second word, fourth letter. Repeat for QWERTY etc.". All it does is contain a set of instructions. You get those, but they're absolutely useless unless you have books in question. A one-time pad is just like that.

Wrong. A book-cipher is breakable because the attacker has some knowledge of what the books may be. The one-time-pad uses a random key. The text in a series of books is not random. To crack a book cipher you can run an exhaustive search over all books known to exist, and you can reasonably assume that only a few of them will give intelligible decryptions. To "crack" a one-time-pad, you have to run an exhaustive search over all possible random strings, which will return an effectively arbitrary number of arbitrary but intelligible strings.
 
Uh, no. I get the feeling you don't know what a one time pad is.

Okay, here's a super simple comparison. Let's take the matter of lockpicking, since you already brought that up. You can use a perfect lockpicking Charm to open any lock, sure. However, if what you're trying to open is a solid metal wall, your perfect lockpicking charm does absolutely nothing. There is no lock to pick, no portal to be opened, no secret mechanism: it's a wall. Anyone trying to argue that you can lockpick a solid metal wall is retarded. It doesn't matter how perfect your lockpicking charm is, there's no lock.

Similarly, applying a perfect decoding charm to a message done with a proper one-time pad (that is - you used a truly random key, your key is at least as long as your string, it is never reused and only you and the intended recipient know it) doesn't work because it does not make sense if you know what a one-time pad is. There's nothing to decode. You might be able to get every possible valid message should you have every possible key, but this is of, heh, questionable utility.

If you want to read that message, you need to do something like, say, find the intended recipient of the message and brainfuck him, find the original sender of the message and brainfuck him, use Solar Stealth to hide in the room while the recipient helpfully provides the info you need to read the message or somehow look backwards in time to when the original sender of the message was writing the message... etc, etc. This is much like, say, deciding to knock down the wall in the above example rather than futilely attempt to pick a lock that isn't there.
Okay, I understand what a OTP is and why realistically it should be uncrackable. But as per the mechanics written, it's a LaPlace demon that tells you the content of a communication, even if it should be impossible.

This means that if all your game is concerned about is something is 'coded' so the Eclipse/Twilight can look cool being able to read it it functions fine, if you apply any realistic sort of encryption methodology in the game it crumbles into a unusable mess.
 
Uhh...yes it is(at least, assuming that it can). If you have both the coded message and the decoded text then even if you don't have the exact mechanics of the cipher at the moment, creating those is trivial.

Also, you still have addressed the issue of if this is a valid use of the charm, then can a Solar look at a message that says "Execute Plan B" and know all the details of plan B? And if not, explain the difference.
Because Plan B isn't being communicated.

Also, no, recreating a cipher from the encoded and decoded text isn't trivial. The difficulty depends on the cipher. You can create a cipher that takes the decoded text and turns it into the encoded text easily, but that doesn't mean you've actually recreated the cipher.
 
Because Plan B isn't being communicated.
Neither is the message. Only instructions to do create the message, in the same way that "Execute Plan B" is an instruction on what to do, but doesn't inform you what Plan B is when subjected to DSE.

I should note that this is, in my view, the weakest of the examples. I think it works, but I prefer Chloe Sullivan's example.
 
Neither is the message. Only instructions to do create the message, in the same way that "Execute Plan B" is an instruction on what to do, but doesn't inform you what Plan B is when subjected to DSE.
... How is that different from any other coded message? Just because you decided to call the key (i.e. information used to turn the message into actual information) the "message" and the message "instructions to create the message", OTPs are mystically different?
 
... How is that different from any other coded message? Just because you decided to call the key (i.e. information used to turn the message into actual information) the "message" and the message "instructions to create the message", OTPs are mystically different?
Yes, because the communication that is sent does not have the information necessary to form the actual message, any more than having the key to any other code would let you know what a message written in that code means without actually, you know, having the message in front of you.

Again, this would be like a Solar unlocking a door in Whitewall from Gem just by holding the key.
 
Last edited:
Yes, because the message that is sent does not have the information necessary to form the actual message, any more than having the key to any other code would let you know what a message written in that code means without actually, you know, having the message in front of you.

Again, this would be like a Solar unlocking a door in Whitewall from Gem just by holding the key.
But the problem is that you don't write a message, give it to your contact, and then later send them a key that you created after the message.
The "key" you keep saying doesn't have the information is actually the message, you're just mislabeling it.
If the "key" is intercepted, they've intercepted the information and lack what is, by definition, the key.

Let's say you give the text "EQNVZ" to your contact. You later decide to send the message "HELLO". You look at EQNVZ and determine that it will combine with XMCKL to create "HELLO".
Based on the only definition of "key" anyone has provided, the key is not XMCKL (like you claim it would be). The key is EQNVZ.
This is because you and your contact both share the text EQNVZ, and you use it to create a piece of text that will come out as HELLO.
Or, to use the appropriate terms, you encrypt HELLO with the key EQNVZ, send XMCKL, and your contact decrypts XMCKL with EQNVZ to HELLO.

If you dispute the definition I'm using for "key", say so and provide a fucking source.
 
But the problem is that you don't write a message, give it to your contact, and then later send them a key that you created after the message.
The "key" you keep saying doesn't have the information is actually the message, you're just mislabeling it.
If the "key" is intercepted, they've intercepted the information and lack what is, by definition, the key.

Let's say you give the text "EQNVZ" to your contact. You later decide to send the message "HELLO". You look at EQNVZ and determine that it will combine with XMCKL to create "HELLO".
Based on the only definition of "key" anyone has provided, the key is not XMCKL (like you claim it would be). The key is EQNVZ.
This is because you and your contact both share the text EQNVZ, and you use it to create a piece of text that will come out as HELLO.
Or, to use the appropriate terms, you encrypt HELLO with the key EQNVZ, send XMCKL, and your contact decrypts XMCKL with EQNVZ to HELLO.

If you dispute the definition I'm using for "key", say so and provide a fucking source.
Okay, let me see if this helps.

With a normal cypher, you have plaintext "HELLO". You apply a process E(ncrypt) to it which, using a set of rules, changes the letters into something else. "GWKKI", let's say. "GWKKI" contains all of the information that was in the plaintext. However, it is now behind an operation; process E, which must be reversed to obtain it.

With a OTP, this is not the case. Instead, you have a long, random pre-generated string, which we'll model as just the alphabet repeated in order endlessly for now, and abbreviate to "ABC...". You then take your plaintext and reverse-encrypt it from the string by counting out which number letter in the string each letter is at. So it would be 8, 23, 7, 26, 3. Then that's what you send.

These are qualitatively different situations. You are not sending an encrypted plaintext, you are sending an operation, which when applied to a string (that can be taken as having been "encrypted" via the addition of vast amounts of junk data between each letter of the message) gets you the original plaintext back out again.

An unencryption operation is not an encrypted message. The two are not the same.

(Bonus points if you can identify the cipher used to get GWKKI from HELLO. :p )
 
These are qualitatively different situations. You are not sending an encrypted plaintext, you are sending an operation, which when applied to a string (that can be taken as having been "encrypted" via the addition of vast amounts of junk data between each letter of the message) gets you the original plaintext back out again.
The operation is no different from an encoded message, with a key of "ABC...", beyond how you're labeling it.
Like... You just described a substitution cipher. That's it. That's all that is. It's a complex substitution cipher.

Process E is the application of the cipher's key. Just because you refuse to acknowledge it as such does not change what it is.
 
However, if what you're trying to open is a solid metal wall, your perfect lockpicking charm does absolutely nothing. There is no lock to pick, no portal to be opened, no secret mechanism: it's a wall. Anyone trying to argue that you can lockpick a solid metal wall is retarded. It doesn't matter how perfect your lockpicking charm is, there's no lock.
There is however, a "Haha, screw you walls, I don't need doors" charm after the perfect lockpicking charm, and the lockpicking charm specifies what happens when it comes into conflict with a perfect locking effect.

If one-time pads and other crypto are vitally important to your game, I could see a charm (with similar requirements to the wall-bypasing charm) that can extract the plaintext from stuff ecoded with an OTP.

The other thing is that generating a true one-time pad (stipulated to be a perfect crypto) must require active essence use as every other published perfect does. Heck, Sidereals probably have the best mechanism for generating OTPs in taking the positions of the fate spiders on the loom at a certain time. The message then contains the ciphertext and a timestamp. DBs could have a charm to generate the pads from the fluctuations of their anima flux, but still have to communicate the pad and chiphertext through separate means.
 
There is however, a "Haha, screw you walls, I don't need doors" charm after the perfect lockpicking charm

:D

I was hoping someone would bring that up as a parallel.

Because no, you are precisely wrong there. Door Evading Technique exactly requires doors. It needs the vulnerability of "a place where one is meant to be able to enter through" to let you walk through. Door Evading Technique cannot walk through walls - it explicitly forbids that as an example of how it can only be used for doors, portals, and other places of intended entrance.

And that's an Essence 4 Charm.
 
I was hoping someone would bring that up as a parallel.
You raise a good point, and thanks for reminding me, I haven't really looked at my books while my game is on hiatus. (Though that door can be "Ten-meter thick slab of solid magical material guarding the entrance tunnel") In this example then, is a message encrypted with an OTP a solid wall, or a wall with a door that cannot be picked?

IIRC, there is an Adjoran charm that lets one ignore walls without needing doors at the cost of 1ha.
 
Would a sidereal charm that did the decoding by telling you how a given person would interpret a given message be appropriate? It still allows you to break codes, maybe even OTPs, but only if you can find someone who could theoretically decode it instead of pulling the info out of nowhere.
 
Would a sidereal charm that did the decoding by telling you how a given person would interpret a given message be appropriate? It still allows you to break codes, maybe even OTPs, but only if you can find someone who could theoretically decode it instead of pulling the info out of nowhere.
It would only be an efficiency improvement, not strictly necessary. Sidereal charms can already decode OTPs. They don't need the key. They don't even need the message.
 
Last edited:
[alert=this argument makes my head hurt]And when something makes my head hurt, PEOPLE DIE GET GRUMBLED AT BY A DECAFFEINATED AMERICAN OVER THE INTERNET!

But seriously, this argument has gone on for long enough, and at this point is basically people repeating themselves. Find a new thing to argue about, please.
[/alert]
Oh thank god!
 
You know, I'd never think I'd miss all the bitching about the Solar Doombots.
Okay, but what if a Solar Doombot tried to decrypt a OTP? :p

More seriously, the success of the X-PROG-311 PSYCHIC RUSSIAN CYBERNETIC WARSQUID GUNSHIP in Panopticon Quest has basically decided me on making an unmanned hellstrider version in Kerisgame as soon as I can (possibly by abuse of Kimbery Artifact-baby Charms). Any suggestions for good component demons? Oooo! I can use a leviluva for the core! Hee. Okay, but what to use for the other parts? Give me ideas, people! Evil ones!
 
Okay, but what if a Solar Doombot tried to decrypt a OTP? :p

More seriously, the success of the X-PROG-311 PSYCHIC RUSSIAN CYBERNETIC WARSQUID GUNSHIP in Panopticon Quest has basically decided me on making an unmanned hellstrider version in Kerisgame as soon as I can (possibly by abuse of Kimbery Artifact-baby Charms). Any suggestions for good component demons? Oooo! I can use a leviluva for the core! Hee. Okay, but what to use for the other parts? Give me ideas, people! Evil ones!

Okidaci- because you can never have enough hot-metal burning passion in your life.
 
After reading through the doc that @Aleph linked, I seriously want to use the Aideara in 3E, specifically as field medics. Would anyone want to help stat them out with me? I'm imagining that they'd be on about the same level as a Neomah, so Essence 2, WP ~4, and an average of 7 dice on things (peaking at 10 or 11). Where I fall flat, however, is Charms. I'm no good at Charm design.
 
Last edited:
Back
Top