that,
refraining from encrypting the subject would be the wrong reaction. Instead, people using
such a MUA should be educated to use another MUA. PGP implementations have undergone
changes which were much more "breaking" than encrypted subject lines.
Best regards,
Binarus
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
gues besides his normal
work (because the management as usual does not understand the importance
and value of such work and the expertise and time which is needed).
Regards,
Binarus
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
reasons has made Enigmail such successful (and GnuPG,
or course).
Regards,
Binarus
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
ing around in TB's installation directory (under Windows, probably a
DLL) and for sure could be updated via TB's update system.
Just my 2 cents ...
Regards,
Binarus
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
productive. What Werner and Patrick have created is mature and
completely trustworthy and surely can't be outranked in the foreseeable
time.
Not wanting to make users install additional software isn't a reasonable
argument for re-inventing the wheel, because AFAIK nothing prevents
people fro
On 14.10.2019 09:17, Patrick Brunschwig wrote:
> Binarus wrote on 13.10.2019 18:27:
> [...]
>> 1) The schedule
>>
>> We have all been educated to update our applications (notably, "internet
>> applications" like browser and email clients) as soon as upd
ers don't have access to. That is, users of
course may do anything they want in their normal email account, but all
messages which are ever sent or received must first be copied somewhere
where they cannot be manipulated or deleted.
I can't imagine how this could be achieved when using tho
On 13.10.2019 18:51, Werner Koch wrote:
> On Sun, 13 Oct 2019 18:27, Binarus said:
>
>> keys' IDs were formally wrong so that key servers didn't accept the
>> keys. The easiest possible solution was to re-generate these keys using
>
> For the records:
bject of an encrypted message
also is one of the essential features (thanks, Patrick, and thanks,
Werner, that you finally have made this possible a while ago!) ...
Just my 2 cents ...
Regards,
Binarus
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
On 19.09.2019 12:31, Stefan Claas via Gnupg-users wrote:
> Binarus wrote:
>
>> IMHO, this system lacks a mandatory unique token in the key ID. The
>> natural choice for such a token would be the email address, because in
>> the first place it is the only thing you know
On 18.09.2019 17:30, Stefan Claas via Gnupg-users wrote:
> Binarus wrote:
>
>> You have stated that my real name must be in the key ID if I would like
>> to have the key certified by Governikus. Does the key ID need to have
>> other personal data in it? After all, as an
On 17.09.2019 21:58, Stefan Claas via Gnupg-users wrote:
> Binarus wrote:
>
>> Actually, I currently don't know anybody who I could ask to sign my
>> keys, and furthermore, the problem is bigger the other way around. Can I
>> trust the key which I found on th
tion
failed due to a malformed or wrongly interpreted addr, but that this
addr can be found nevertheless on the key server. Therefore, we need to
structure the ID so that there is one dedicated place where addrs can be
stored and easily parsed, which
shed just yesterday? Glad
that I noticed this just in time - I already was typing "Does anybody
know how widespread those proposals are, and which one has won?" :-)
Regards,
Binarus
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
ning means: you encrypt a message hash
with your private key, the receiver decrypts the hash using your public
key and checks if the decrypted hash matches the message). So deleting
public keys from a key server might be a bad idea anyway.
Regards,
Binarus
__
but with the name quoted.
In every case, I am happy now, as long as IDs consisting only of the
actual mail address remain allowed. Personally, I currently don't need
to have my name or other fancy text in my keys' IDs. I suppose that
somebody who wants to write me an encrypted mess
On 16.09.2019 12:58, Claus Assmann wrote:
> On Mon, Sep 16, 2019, Binarus wrote:
>
>> Surname, Forename | Company
>
>> Commas are not allowed as part of email addresses. While I knew that, I
>
> unless quoted, e.g.,
> "Surname, Forename | Company"
On 14.09.2019 13:15, Binarus wrote:
> I have used the Thunderbird / Enigmail / Gpg4Win troika for quite a
> while without any issue. Yesterday, I had to reinstall, and while doing
> so, upgraded to the newest versions of that packages, and while I was at
> it, revoked my old (1024-b
ng ...
Again, thank you very much for your support and time.
Regards,
Binarus
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
re.
I have quite a good idea of how PGP encryption works in general, but I
never (until now) have used GPG's command line interface (just hadn't to
do so because Enigmail did its job quite good), so it would be nice if
the issue could be explained in simple words :-)
Thank you very m
their PIN for a UK bank
> account (it IS as random a selection as any other 4-digit number).
Yes, in a mathematical sense. Taking the human factor into account, that person
has been very unlucky.
If you are interested in the details, please refer to my post from 2017-07-12
On 15.07.2017 16:40, MFPA wrote:
>
>
> On Thursday 13 July 2017 at 7:18:41 AM, in
> , Binarus wrote:-
>
>
>> I don't think so. Banking chip cards contain
>> mechanisms for local PIN
>> verification. You can see that an ATM (or the card)
>> imme
On 15.07.2017 12:36, MFPA wrote:
>
>
> On Wednesday 12 July 2017 at 11:01:35 AM, in
> , Binarus wrote:-
>
>
>> As far as I know, no bank will be able to tell you
>> your PIN if you have
>> forgotten it
>
> They can in the UK. For example, see
&g
On 13.07.2017 01:19, MFPA wrote:
>
>
> On Wednesday 12 July 2017 at 6:51:42 AM, in
> , Binarus wrote:-
>
>
>> and this means that such software would
>> have to run on the
>> card.
>
> Or The ATM.
You are right. The ATM will get hold of the PIN in
On 13.07.2017 01:23, MFPA wrote:
>
>
> On Wednesday 12 July 2017 at 3:15:09 PM, in
> , Binarus wrote:-
>
>
>
>> (if the
>> PIN needs to be
>> stored at all in some backend which I doubt).
>
> The Bank must know the PIN (or a hash). Otherwise the
On 12.07.2017 12:10, Peter Lebbing wrote:
> On 12/07/17 07:51, Binarus wrote:
>> Furthermore (not being sure, so read with care), I think that the bank
>> does not know your pin
>
> When my bank card is replaced because its validity is about to end, the
> new card has the
On 12.07.2017 12:27, NdK wrote:
> Il 12/07/2017 12:01, Binarus ha scritto:
>
>> Not sure about that. Similar to serious websites which don't store your
>> password in clear text, but do store the password's hash instead, I
>> would expect that banks don'
On 12.07.2017 11:42, Guan Xin wrote:
> On Wed, Jul 12, 2017 at 1:51 PM, Binarus <mailto:li...@binarus.de>> wrote:
>
> On 11.07.2017 20:38, MFPA wrote:
> >
> >
> > On Tuesday 11 July 2017 at 8:44:48 AM, in
> > <mailto:mid%3a34
your name sounds German):
http://www.sueddeutsche.de/wissen/unsichere-pin-codes-erwischt-1.1486312
I don't have time for a thorough research right now, but this article
gives us an idea. I don't think the situation has changed much since
2012 ...
Regards,
Binarus
On 11.07.2017 20:38, MFPA wrote:
>
>
> On Tuesday 11 July 2017 at 8:44:48 AM, in
> , Binarus wrote:-
>
>
>> I am not sure if this is an intentional limitation of
>> the cards (to
>> prevent users from choosing idiotic pins like 1234 or
>> their birthda
On 11.07.2017 14:38, Jerry wrote:
> On Tue, 11 Jul 2017 12:32:56 +0200, Binarus stated:
>
> [...]
>> I am not completely sure if I got you right. Wouldn't that mean that I
>> have to lose my card, the bad person then makes two guesses, then I get
>> back my card
On 11.07.2017 11:48, Matthias Mansfeld wrote:
> On 11 Jul 2017 at 9:44, Binarus wrote:
>
>> On 10.07.2017 17:42, Guan Xin wrote:
>>> This is probably a general question --
>>>
>>> I have never seen a German bank that allows changing the PIN of a card.
>&g
On 11.07.2017 14:32, NdK wrote:
> Il 11/07/2017 12:32, Binarus ha scritto:
>
>> But now, being a German citizen, try the same thing with eBay, Facebook,
>> LinkedIn, PayPal and so on ... no thanks.
> Why should heirs have access to social accounts? Paypal, otoh, is a bank
On 11.07.2017 10:14, NdK wrote:
> Il 11/07/2017 09:44, Binarus ha scritto:
>
>> - If somebody tries to brute force the pin (or online banking password),
>> the access will be permanently denied if there are more than 3 failures
>> (the exact number may vary). That means th
could have some relative you trust memorize
your master password. But since he won't use it regularly (hopefully),
he probably will forget it after short time ...
Regards,
Binarus
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
would be some sort of a "new, modern PGP certificate". If I only had
known that earlier ...
Sorry for the lengthy posts, and again: Thanks you very much!
Binarus
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
onsider that the
certificate I have been given could be an S/MIME certificate. Now that I
know that, I am quite confident that I will be able to configure and use
S/MIME properly.
Once again, a big thanks for all the help and for your time!
Regards,
Binarus
___
mand line in other
situations).
Slightly off-topic: Does anybody eventually know if and when Enigmail /
gpg4win will support certificates?
Thank you very much,
Binarus
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
his post.
Thank you very much,
Binarus
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
39 matches
Mail list logo
