[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GPGME
From: |
Daiki Ueno |
Subject: |
Re: GPGME |
Date: |
Wed, 29 Jun 2011 22:15:02 +0900 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) |
Ted Zlatanov <address@hidden> writes:
> DU> I remember that the problem of encrypt.el was that the data format is
> DU> not interoperable and the algorithm used is not interchangeable though
> DU> the API might be neutral.
>
> Is that a problem, if the intent is to provide an Emacs facility?
The benefit using the standard GPG format is that it embeds what
algorithm is used in data.
If Emacs provides bare cipher algorithms, someone may write encryption
routines with their own format which won't be interoperable - that is a
problem I think. For my case, I had used GPass
http://gpass.sourceforge.net as my password manager (currently
unmaintained). It turned out that it used bare Blowfish internally and
I had to write a script to salvage my password data.
> I'm asking if, instead of a new package, we can use `epg-encrypt-string'
> to provide symmetric encryption without calling GPG externally. It can
> provide it in any format and with any symmetric cipher you think would
> make sense. But if you don't think so, then we need a new package to
> provide that functionality.
I don't care about it.
Regards,
--
Daiki Ueno
- Re: secure plist store, (continued)
- Re: secure plist store, Ted Zlatanov, 2011/06/29
- Re: secure plist store, Ted Zlatanov, 2011/06/29
- Re: secure plist store, Daiki Ueno, 2011/06/30
- Re: secure plist store, Ted Zlatanov, 2011/06/30
- Re: secure plist store, Daiki Ueno, 2011/06/30
- Re: secure plist store, Ted Zlatanov, 2011/06/30
- Re: secure plist store, Daiki Ueno, 2011/06/30
- Re: secure plist store, Ted Zlatanov, 2011/06/30
- Re: secure plist store, Daiki Ueno, 2011/06/30
- Re: GPGME, Ted Zlatanov, 2011/06/29
- Re: GPGME,
Daiki Ueno <=
- Re: GPGME, Ted Zlatanov, 2011/06/29
- Re: GPGME, Daiki Ueno, 2011/06/29
- Re: GPGME, Ted Zlatanov, 2011/06/30
- Re: Opportunistic STARTTLS in smtpmail.el, Ted Zlatanov, 2011/06/02
- Re: Opportunistic STARTTLS in smtpmail.el, Daiki Ueno, 2011/06/02
Re: Opportunistic STARTTLS in smtpmail.el, Lars Magne Ingebrigtsen, 2011/06/03