[tor-dev] A new idea for email encryption on tor
keifer.bly at gmail.com
Sun Mar 28 17:44:46 UTC 2021
Well, you do. It is stored on your local machine only.
On Wed, Dec 2, 2020 at 1:10 PM Wisdom With Rahul <rahulbhatia172 at gmail.com>
> This idea is interesting but who owns all the keys?
> Thanks and regards!
> On Fri 13 Nov, 2020, 6:49 AM Keifer Bly, <keifer.bly at gmail.com> wrote:
>> Well, the mechanism is that it overwrites the key ever time, so each
>> message has its own unique key, also the receiver needs to verify the key
>> file with the built in tool to be able to use it. So an attacker does not
>> know this the only way to get this information is from the person that
>> created the message as the need when the OS originally generated the
>> message, not when it was uploaded as an attachment somewhere. That's what I
>> was thinking. I will look into the communities suggested, thanks very much.
>> On Thu, Nov 12, 2020 at 1:27 PM Santiago Torres-Arias <
>> santiago at archlinux.org> wrote:
>>> On Thu, Nov 12, 2020 at 11:19:44AM -0800, Keifer Bly wrote:
>>> > Hi there,
>>> > So I have a new email encryption system which requires that the user
>>> > the specific key file generated for a message rather than the password,
>>> > specifically this software generates a unique key file for a specific
>>> > message every time a message is created. The user then enters the date
>>> > time the message was created. Without the original key file the message
>>> > can't be opened;
>>> > https://www.youtube.com/watch?v=R0W7OVdNrOA
>>> > Here is a video showing the software. I've built it for Windows and
>>> Mac OS.
>>> > I was wondering if this could be implemented in tor. I think it would
>>> be an
>>> > interesting idea for a tor based email system to make the messages
>>> > unrecoverable after use.
>>> I'm not a tor-dev, so I can't comment on the interest, but it appears to
>>> me that the value added of this idea (basically, using time to seed a
>>> PRF/KDF) is very little. All in all, using time to seed keys is not the
>>> best idea. It also seems to be on top of PGP, so I'm pretty convinced
>>> this doesn't provide perfect forward-secrecy unless you're layering any
>>> sort of session key ratcheting mechanism yourself.
>>> I think the goal is laudable, but I suggest getting a little bit more
>>> involved in cryptography engineering communities to see learn, develop
>>> and eventually help change the status quo.
>>> tor-dev mailing list
>>> tor-dev at lists.torproject.org
>> tor-dev mailing list
>> tor-dev at lists.torproject.org
> tor-dev mailing list
> tor-dev at lists.torproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tor-dev