LightfieldAI-native CRM that builds itself and does work for you
Promoted
AegisMeetings
Meeting notes sealed — even if our DB is stolen
22 followers
Meeting notes sealed — even if our DB is stolen
22 followers
Built so even with a stolen DB + root everywhere, I still can’t decrypt finished meetings (audio, transcripts, summaries, vocab). Honest limit: one-job ASR RAM window—not E2EE. Founding limited · pay first, then vault. ≤30h transcription in 7 days → unconditional refund. Poke holes welcome. https://aegismeetings.com/
In the process where audio keys are re-wrapped using the 'transcription host public key' and transmitted to the transcription cluster, how does the system ensure forward secrecy and manage the key lifecycle for the transcription host’s asymmetric key pair? If the transcription host's private key were compromised in the future, could an attacker retroactively decrypt audio keys stored in intercepted historical Service Bus task messages?
@sy_hsu Great catch. Today the transcription host uses a long-lived key pair: audio CEKs are wrapped to that pubkey, sent only in the Service Bus job (not stored in our DB), unwrapped in RAM, then wiped after ASR.
So no true forward secrecy on that wrap path yet — if the host private key were stolen later and someone had old intercepted SB payloads + blob ciphertext, those jobs could be unwrapped. We mitigate by not persisting wraps, short-lived queue messages, and a locked-down host — but that’s operational, not FS.
Ephemeral / per-job wrapping (+ key rotation) is the roadmap. Happy to hear design critiques.
想確認一個最基本的：
音檔是加密存起來的，那要解開一定得有對應的 key。
這把解音檔的 key（轉錄主機私鑰）是長期放在你們伺服器端的嗎？
如果是，那是不是代表——只要這把 key 在，你們技術上其實有能力解開任何一場存起來的音檔？
重點先分清楚：我們不是用轉錄主機的 RSA 去封音檔本身，而是封「這一場用來加密音檔的對稱金鑰」。
其實有三把不同的鑰匙：
會議音訊金鑰（對稱）——真正用來加密音檔（以及相關密封資料）的那把。
轉錄主機 RSA 金鑰對——公鑰在瀏覽器端；私鑰只在轉錄主機。用途只有一件：把「這一場的音訊金鑰」安全交給 轉錄主機，只服務這一次任務。
你的裝置主金鑰（RSA）——私鑰從不離開你的裝置。用途是長期保管：資料庫裡存的金鑰材料是用「你的」公鑰封的，之後只有你的裝置能解開密封逐字稿等內容。
流程是：瀏覽器產生這一場的音訊金鑰 → 用它加密音檔 → 再用轉錄主機公鑰把這把音訊金鑰包起來，只放進當次任務訊息（不寫進資料庫）→ 轉錄主機用自己的私鑰在記憶體解開、轉錄，結束後連金鑰帶明文一起清掉。
所以「轉錄主機私鑰還在＝就能解任何存起來的音檔」不成立。那把私鑰只能解「專門封給它的信封」，而那種信封不持久保存。真正長期存下來的，是封給你的公鑰的材料——轉錄主機的私鑰解不開。
唯一要誠實講的例外：AI 轉錄時必須真的「聽」一次，那短暫時段我們叫誠實窗口期（約數分鐘、只在記憶體、用完即清）。若要重轉舊會議，仍須由你的裝置重新授權金鑰，我們無法自己翻舊帳。
一句話：轉錄主機金鑰＝當次任務的信差；你的主金鑰＝長期鎖；音檔本身則由每場會議自己的對稱金鑰加密。
love that you're putting the refund policy and the honest "not E2EE" caveat right on the landing page instead of burying it. the transparency about the ASR RAM window basically invites scrutiny and that kind of openness is rare these days. poking the link now to see if the vault holds up.
@metehanzgg5 thanks — refund + the “not E2EE” bit are on the page on purpose.
seriously, go poke it. if you want to test end-to-end then hit refund after, that’s fine — then tell me straight if anything felt like we were bullshitting.
one catch: after a refund the system blocks buying again (keeps abuse down). if you tested, refunded, and actually want to keep using it, email service@aegismeetings.com and I’ll reopen purchase for you.
Tried it with a couple of calls and liked that the security limits are spelled out plainly instead of buried. The ASR decrypt window caveat is the kind of honesty I'd want before trusting anything with sensitive transcripts.
@nazmiyeemi0thh Appreciate that. We put the ASR decrypt window up front on purpose — no buried caveats. Glad a few calls felt okay.
What would make you trust it more next — tighter wording, or a clear “no cloud ASR” option?
the way you framed the actual e2ee boundary around the ASR decrypt window is refreshingly honest, most "secure meeting" tools just hand-wave that part and you called it out clean.
@zehra1029646 Thanks Zehra. That’s exactly what we were aiming for，a real implementation, not a marketing fog machine. No fake “E2EE everywhere,” no soft edges on the hard parts.
We name the weakness on purpose: ASR needs a short decrypt window in RAM. Then we document how we shrink it，job-scoped keys, no durable plaintext at rest, isolated transcription host, wipe after the job. Honesty first; controls second.
If anything is unclear, or you want to dig deeper，even sharp questions，I’m very happy to answer.
the honesty about the ASR decrypt window is refreshing. most E2EE products bury their limitations or hide them behind marketing, but you just put the actual tradeoff front and center. that kind of transparency builds more trust than the encryption itself.
@gnlsincarytnm Thanks — that means a lot. We debated soft-labeling it “E2EE with a caveat” and decided that just teaches people the wrong mental model. If ASR has to see audio once, say so up front; trust is cheaper to earn that way than to repair later.
If anything in the whitepaper still feels hand-wavy (especially the processing window), poke it. Prefer hard questions over compliments.