[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: favicon.png (106 KB, 512x512)
106 KB
106 KB PNG
>be me
>get tired of Signal/Telegram botnets
>decide to roll my own messenger
>call it Cipher Pulse

It's actually done and not just another vaporware project.

Here's the deal:

E2EE by default. Server is a dumb relay, zero-knowledge on your shit.
Proper crypto. Not just crypto.js from a 2016 tutorial. It uses SRP for auth, X3DH for session init, and Double Ratchet for PFS. If you know, you know.
Multi-device. Keys are deterministically derived from a master seed (BIP-39/DiceKey), so you can get your chats on a new device without scanning a million QR codes.
Burn after reading. Self-destructing messages. Standard stuff.
Time-locked messages. This is the cool part. You can send a message that can't be opened until a specific time. The unlock time is secured by a blockchain timestamp, so you can't cheat it by changing your system clock. It's immutable.
P2P mode. If you can, it goes direct. If not, it uses the relay.
Encrypted file attachments. Because sometimes you need to send more than just text.
It's open source, so you can actually audit the code instead of just trusting the marketing.

Honest limitations so you don't waste your time:

It won't save you if you're a retard and click on cool_game.exe. Endpoint compromise is still a problem.
It's not for glow-op level anonymity. It's for keeping your messages private from the server and corporations.
The UI is clean, not some rainbow-farting Discord clone.

Repo: https://github.com/Oykdo/cipher
Web Demo: https://cipher-pulse.onrender.com/

Break it. Find flaws. Tell me why it's shit.

Or don't. I don't care. its late here in euw brb in a few hours
>>
>>107575249
sounds cool where's the appstore link
>>
ty, asap for a mobile version, going to bed now i will answer questions in a few hours
>>
Well worst case I just use it like Omegle
>>
>>107575249
Will check.
Not a fan of electron, but I get and as a single dev most likely...
>>
File: ai.png (9 KB, 243x127)
9 KB
9 KB PNG
>It won't save you if you're a retard and click on cool_game.exe. Endpoint compromise is still a problem.
>It's not for glow-op level anonymity. It's for keeping your messages private from the server and corporations.
>The UI is clean, not some rainbow-farting Discord clone.
>>
>>107575836
Its just an IP grabber
>>
You could call it "vibe coding" + a bunch of CLIs, mostly just siccing factory.ai droids on the problem.

Took about 3 months of pure puzzling and passion. Glad for the (You)s, they're all going into the bug tracker.
>>
>

> ### **Time-Lock Messages**
>Messages can be locked until a specific time using **blockchain anchoring**:
>- Bitcoin integration for tamper-proof timestamps
>- Cryptographic proof of time-lock validity
>- Impossible to unlock before scheduled time (even by you!)
>- Use cases: scheduled announcements, posthumous messages, time capsules

Enforced by what, a trusted client software that could be patched to ignore the current Bitcoin block height?
>>
>>107575836
Fuck you're right the entire post and some of OP's replies are AI-generated fuck
>>
You're right to be skeptical. A simple ‘if’ statement in the client is worthless.

The enforcement isn't in the client's code ; it's in the cryptography. A patched client is useless because the decryption key literally doesn't exist until the scheduled time.

We use the Bitcoin network as a decentralized, tamper-proof clock. The block header is the proof that the time has occurred.

The missing part of the key is derived by hashing a specific, future Bitcoin block header.
For example: Key_Part_B = SHA256(Block_Header_at_Height_X).

The client can't unlock the message early because it can't invent the required piece of the key. It must wait for the Bitcoin network to mine the specific block and provide the data needed to reconstruct the key.
>>
Arguing against using AI for translation/adaptation in 2025 is like insisting on writing assembly code when you have Python. It's not about being lazy, it's about using the right tool for the job to focus on what matters : the topic
>>
>>107577116
But then how does the sender of the message know how to encrypt it? It can't divine the key either.
>>
>>107575249
Cool project OP!

>>107578503
Do you just loop over encrypted messages every new block looking for unlocks?

Also im not sure about the cipher-pulse: file:"../.." in the package json. Shouldnt this package have its own scoping than importing itself through root?

If my js understanding is correct, and other packages can be inserted there and functionally overload legitmate functions and create faulty builds

Mightvbe a vibe fragment
>>
>>107575249
I DONT GIVE A FUCK ABOUT THE FUCKING CODE! i just want to download this stupid fucking application and use it

WHY IS THERE CODE??? MAKE A FUCKING .EXE FILE AND GIVE IT TO ME. these dumbfucks think that everyone is a developer and understands code. well i am not and i don't understand it. I only know to download and install applications. SO WHY THE FUCK IS THERE CODE? make an EXE file and give it to me. STUPID FUCKING SMELLY NERDS
>>
>>107575803
Learn English, angloid scum.
>>
>>107575249
so the messages are time locked by the amount of work needed to grow the blockchain? i see
Couldn't you hack the software to make it set that is_blockchain_old_enough boolean to be true and then have the program progress?
Also messages that are only readable after x date is kinda lame. Messages that are only readable before x date is more interesting
>>
No, it doesn't loop over all the messages.

That would be very inefficient. Instead, we use a special, optimized database index that flags messages with a "time-lock."

Think of it like this: each time-locked message is tagged with the specific block number when it should be unlocked. When a new block is mined, the system simply asks the database: "Give me all messages tagged with a block number that is less than or equal to the current one."

This is a very fast and direct lookup. The server never sees the content of the messages, it only handles the encrypted data and the block number. The actual decryption always happens securely on your own device.

//

If you're not into the code or just don't have the time, you can simply try it out on your phone right here: https://cipher-pulse.onrender.com

//

"so the messages are time locked by the amount of work needed to grow the blockchain? i see
Couldn't you hack the software to make it set that is_blockchain_old_enough boolean to be true and then have the program progress?
Also messages that are only readable after x date is kinda lame. Messages that are only readable before x date is more interesting"


Nah, that would be inefficient as fuck.

It's an indexed lookup on the unlock_block_height column. The server just asks the DB for all messages where unlock_block_height <= currentBlockHeight.

Server never sees the plaintext, it just filters on an integer and forwards the encrypted blob.
>>
Neat. I'll leave a bottled message for you to open in the year of 2040
>>
Or , you can contribute so I can stock my fridge, get some coffee and smokes to move on to the next part. It's expensive keeping this machine running! joke apart
>>
File: 27.png (18 KB, 250x250)
18 KB
18 KB PNG
https://github.com/dchest/tweetnacl-js?tab=readme-ov-file#hash-length-extension-attacks

https://github.com/Oykdo/cipher/blob/6233a47ab825b16a44f082a789c0a93aee7e43dc/apps/frontend/src/lib/crypto.ts#L5

might be worth reasoning about switching to keccak, this tweetenacl library is pretty old and sha-2 got this legnth extension attack thing

https://www.youtube.com/watch?v=gOIBUe1fjX0
>>
>>107578503
>But then how does the sender of the message know how to encrypt it? It can't divine the key either.
Please respond
>>
>>107581866
Disregard keccak/SHA-3, embrace BLAKE2b
>>
>>107575249
Shit bro, you created what I was working on except I didn't utilize blockchain.
>>
>>107582406
haha, any reason?

from this https://medium.com/asecuritysite-when-bob-met-alice/ripemd160-f28062242045

it may be wiser for op to double hash ripemd160 + sha256 to try to use satoshis solutions at length extension to keep conformity with the bitcoin blockchain
>>
>>107577198
>>107578503
Your inability to answer this question isn't really a win for AI slop.

The answer is, you can't timelock encrypt like this - sorry to say the AI lied to you. Your AI did not come up with a novel cryptographic solution. Now delete the webpage and github please before anyone actually thinks this works.
>>
will reply later, anons got some important legal shit to take care of tomorrow (gangstalkers, reee) and need to get some sleep thanks for all the replies and suggestions (especially for potential exploits/vulns) to make the app less shit feel free to open issues on the git
>>
https://github.com/hashchan/time-anchor

here's a read on your cryptgraphic primitive op. I dont see any way around a commit reveal scheme

but this way in zeroledge the commiter only pays gas once and the reveal can be anyone or in a batch with many

still prototype but i think the general direction is sound
>>
>>107575249
Cool concept. I'd like to see an in-depth independent security audit of it at some point, but since it's new, that obviously won't be out for a while.

Looking at your feature roadmap, it looks like you don't have group chats yet, but that this is planned. This is good to see, since I know plenty of folks who use encrypted messengers for group chats. I also see post-quantum is planned as well. This would put you on par with SimpleX, which seems to be the only worthwhile messenger that actually cares about that.
>>
Fuck off frenchie
>>
Looks cool OP. Are you confident enough in this project to grow it into something normal people will use or is this just going to be 3 /g/ anons hiding their homoerotic roleplay chats from google?
>>
kek holy aislop
>>
>AES GCM
Signal recommends AES-CBC or AES-SIV because key-IV reuse is catastrophic for AES-GCM.

>ENCRYPT(mk, plaintext, associated_data): This function is recommended to be implemented with an AEAD encryption scheme based on either SIV or a composition of CBC with HMAC [5], [14]. These schemes provide some misuse-resistance in case a key is mistakenly used multiple times.

https://signal.org/docs/specifications/doubleratchet/



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.