i jst came up wid an idea n i dnt knw how to proceed furthr....i'd lyk to encrypt data in such a way dats its decrptd in stages. initial stages when overcome wud show irrelevant dat(nt garbage)xtractd frm d original data...decrption methods wud vary in each stage.... more complicated in d lattr stages. a countr wud b set off vn d data wud b sent n if d sender dusnt recieve an acknowledgmnt withn stipulatd tym...a self destructive program attachd 2 all d packet wud b turnd on....
i ws thnkin f doin this in c...bt hv no idea if any othr language wud b bettr...

Dani AI

Generated

— the “staged decryption” concept can be made practical, but it needs a clearer threat model and a safe key-release mechanism. was heading in the right direction about layered approaches, and ’s bluntness aside, two of your original ideas need correction: you cannot reliably make arbitrary remote machines execute code from a network packet, and you cannot force deletion of data on endpoints you don’t control without legal/operational control.

Practical approaches that match your goal:

  • Key-release / key-wrapping: encrypt the data once with a final key, then publish successive wrapped versions of that key so recipients recover the final key stage-by-stage. This keeps the ciphertext stable and limits real-data exposure to when the final key is reconstructed.
  • Threshold / secret-sharing: split the decryption key (e.g., Shamir’s Secret Sharing) so parts become available across stages or from different parties.
  • Timed-release puzzles for automatic delays (time-lock puzzles) if you want a provable delay without a trusted server.

Always use authenticated encryption for each layer (AEAD: AES-GCM or ChaCha20-Poly1305). Do not design your own crypto primitives; use vetted libraries.

For the “self-destruct” idea: don’t rely on remote code execution. Use cryptographic erasure and key-control instead—store only ciphertext on untrusted hosts, keep the single decryption key on a server or HSM, and make keys short-lived or revokeable (heartbeat/lease). If you control endpoints (corporate devices), device-management tools can perform remote wipe, but embedding executables in packets is unsafe and often illegal.

Simple high-level pseudocode:

final_key = random()
ct = AEAD_encrypt(final_key, plaintext)
for stage in stages:
    publish(wrap_key(stage.key, final_key))
# receiver unwraps stage keys to recover final_key, then AEAD_decrypt(ct)

See Shamir’s Secret Sharing and time-lock puzzles for patterns. Use libraries like libsodium and follow secure key-management practices.

Recommended Answers

All 2 Replies

Try asking that question again without letting the cat walk on the keyboard so we can understand WTF you're saying.

"i jst came up wid an idea n i dnt knw how to proceed furthr....i'd lyk to encrypt data in such a way dats its decrptd in stages. initial stages when overcome wud show irrelevant dat(nt garbage)xtractd frm d original data...decrption methods wud vary in each stage.... more complicated in d lattr stages. "

Don't know anything about c or any other languages for that matter but I can tell you that you could do this easily with python with the PyCrypto module... unless I'm missing your point here you just have to go:

SomeEncrypt(plaintext)--> SomeOtherEncrypt(crypttext1 + sprinkles of garbage) ---> etc etc.

And then reverse it for decryption.

"a countr wud b set off vn d data wud b sent n if d sender dusnt recieve an acknowledgmnt withn stipulatd tym...a self destructive program attachd 2 all d packet wud b turnd on....

Umm can't help you there, I'm no expert but that doesn't really sound possible to me. You can't just include code in packets and have it execute it on other systems as far as I know. If you could do that, well, things would be pretty different on the internet wouldn't they? Besides, you don't really have a packet anymore once your talking about executing code right? You've retrieved the payload from that packet
and are trying to do something with the data that packet contained.

And yeah, not to be rude but, try english FFS, that was ridiculous.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.