age-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Andrew Rowley
> Sent: Thursday, August 29, 2019 6:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: vendor distributes their private key
>
> On 29/08/2019 9:18 am, Charles Mills
.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Andrew Rowley
Sent: Thursday, August 29, 2019 6:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key
On 29/08/2019 9:18 am, Charles Mills wrote:
On 29/08/2019 9:18 am, Charles Mills wrote:
But for certificate-based client authentication, the server admin must send the
client admin a client certificate AND its private key. Why? Philosophically,
because a client certificate signed by a trusted CA does not prove the
authenticity of the c
o customers.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Charles Mills
Sent: Wednesday, August 28, 2019 7:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private ke
> crypto non-repudiation can show it came from your machine
I certainly agree with this, but you can restrict what "your machine" is so
that it's a lot better than just "came from a particular PC" or "came from a
particular mainframe". For example, the private key may be stored in something
yo
-
From: IBM Mainframe Discussion List On Behalf Of
Mike Wawiorko
Sent: 29 August 2019 10:51
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key
This mail originated from outside our organisation -
014ab5cdfb21-dmarc-requ...@listserv.ua.edu
Charles sent
n List On Behalf Of
Charles Mills
Sent: 29 August 2019 00:19
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key
...
But for certificate-based client authentication, the server admin must send the
client admin a client certificate AND its private key. Why? Philo
I'm sure everyone is tired of this thread but I wanted to jump in here and say
that anyone -- including me -- who said "you should never get a private key
from the owners of some server you want to connect to" was potentially wrong.
Yes, yes, of course, sending out root CA or Intermediate certif
sme...@gmu.edu (Seymour J Metz) writes:
> The proper way to provide encryption and non-repudiation is to have
> two key pairs. You sign a message using your private key. People
> wanting to send you encrypted data encrypt using your public key. So
> if foo wants to send bar a signed encrypted docum
My personal email provider (see below) just recently supported ed25519 for
users public/private key pairs. They still support RSA keys of course.
Mark Jacobs
Sent from ProtonMail, Swiss-based encrypted email.
GPG Public Key -
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@proto
Keeping with ibm-main tradition, I'll steer this into a different ditch :-)
"Seriously, stop using RSA"
This is a very interesting writeup/presentation, I've shorted the URL for
obvious reasons
https://tinyurl.com/yxw5xvmv
IMO, ECDSA (NIST curves) are much better than RSA, although researchers
s
" Non-repudiation for the message is not guaranteed by a hash. There is more
than 1 message that could match that hash. "
The breadth of privacy on the internet as we know it depends upon being able to
trust that a hashing algo + cryptographic signature verifies the
non-repudiation of the sende
A few random comments about this discussion:
1. Someone mentioned performance. If that is a concern, use hardware to do
the public-key algorithm - for example the Crypto Express HSM.
2. Remember that not all public-key algorithms can directly encrypt data. For
example, RSA can, but Elliptic
I actually might share that with this vendor! They still have not
realized/acknowledged their error.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: IN
Charles Mills wrote, re hash uniqueness:
>https://en.wikipedia.org/wiki/Cryptographic_hash_function
>Read the third and fourth bullets.
Indeed. Since the odds of a hash collision with any modern hashing algorithm
are lower than the odds of a random bit-flip, it's not
worth worrying about.
, 2019 3:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key
Non-repudiation for the message is not guaranteed by a hash. There is more
than 1 message that could match that hash.
Jon.
--
For IBM
Non-repudiation for the message is not guaranteed by a hash. There is more
than 1 message that could match that hash.
Jon.
On Monday, August 26, 2019, 02:42:27 PM PDT, Charles Mills
wrote:
Yow! Expensive in terms of CPU time.
Wouldn't (ideally at least) foo encrypt it with a random secr
: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key
Those alternatives also involve two pairs of keys.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu
_
From: IBM Mainframe Discussion List on behalf of
zMan
Sent: Monday, August 26, 2019 5:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key
Isn't that what was just discussed? What am I missing here?
On Mon, Aug 26, 2019 at 4:42 PM Seymour J Metz wrote
PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key
The proper way to provide encryption and non-repudiation is to have two key
pairs. You sign a message using your private key. People wanting to send you
encrypted data encrypt using your public key. So if foo wants to se
STSERV.UA.EDU
Subject: Re: vendor distributes their private key
CM Poncelet wrote:
>Because a sender does not need to have an own public/private key-pair,
>but needs only the public keys of the recipients to send encrypted
>emails to them.
Ah, ok. Reveals my ignorance of how PGP w
Isn't that what was just discussed? What am I missing here?
On Mon, Aug 26, 2019 at 4:42 PM Seymour J Metz wrote:
> The proper way to provide encryption and non-repudiation is to have two
> key pairs. You sign a message using your private key. People wanting to
> send you encrypted data encrypt
U
Subject: Re: vendor distributes their private key
I vaguely recall that there was a third prime number involved in the algorithm
that was static for RSA. Do they still have this third prime? Could it be that
they use this to eliminate this possibility?
Jon.
On Saturday, August 24, 2019,
x27;s private key and
bar's publickey.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Phil Smith III
Sent: Monday, August 26, 2019 4:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor d
CM Poncelet wrote:
>Because a sender does not need to have an own public/private key-pair,
>but needs only the public keys of the recipients to send encrypted
>emails to them.
Ah, ok. Reveals my ignorance of how PGP works. Voltage SecureMail uses both,
providing that non-repudiation; I gues
Because a sender does not need to have an own public/private key-pair,
but needs only the public keys of the recipients to send encrypted
emails to them.
BTW Some links if interested in putting this to the test:
[PRZ's website:]
https://philzimmermann.com/EN/findpgp/
[free GPG/PGP websites:]
On Mon, 26 Aug 2019 17:42:35 +, Seymour J Metz wrote:
>RSA only involves two primes. See
>https://en.wikipedia.org/wiki/RSA_(cryptosystem)
From: Jon Perryman
Sent: Saturday, August 24, 2019 4:29 PM
I vaguely recall that there was a third prime numb
-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key
I vaguely recall that there was a third prime number involved in the algorithm
that was static for RSA. Do they still have this third prime? Could it be that
they use this to eliminate this possibility?
Jon.
On Saturday
CM Poncelet wrote:
>Possibly - but probably not "encrypted with ... possibly sender's
>private key"
? Why do you say that? Doing so provides both security and non-repudiation. I
may be misunderstanding your point.
--
For
Possibly - but probably not "encrypted with ... possibly sender's
private key"
On 26/08/2019 02:17, Phil Smith III wrote:
> CM Poncelet wrote:
>
>> PGP allows sending encrypted emails/data to multiple recipients, where
>> each recipient has a different private key, and this works AOK (but no
>>
ssage-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Phil Smith III
Sent: Sunday, August 25, 2019 6:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key
CM Poncelet wrote:
>PGP allows sending encrypted emails/data to
CM Poncelet wrote:
>PGP allows sending encrypted emails/data to multiple recipients, where
>each recipient has a different private key, and this works AOK (but no
>idea how).
Trivial: the actual payload is encrypted with a random symmetric key. Then THAT
key is encrypted with the public ke
Vendors should restrict read access to their FTP upload sites in case there is
sensitive data included. Dumps are a good example where customers cannot
sanitize the file. There are some customers that will not send a dump because
they cannot sanitize it. In those situations, you are forced to s
On 22 Aug 2019 05:57:37 -0700, in bit.listserv.ibm-main
(Message-ID:<0049105969039769.wa.jiveycio.sc@listserv.ua.edu>)
ji...@cio.sc.gov (Joel M Ivey) wrote:
First, they provided a password-protected p12 file,
describing it as containing the "root, intermediate, and
private certs". I requ
No need for a private key registry because verifying the public key is
sufficient. There are public key registries but I doubt they validate
duplication.
Remember this is PGP (Pretty Good Privacy - not perfect), so there are multiple
factors that were considered. In this case, duplicate key pa
I vaguely recall that there was a third prime number involved in the algorithm
that was static for RSA. Do they still have this third prime? Could it be that
they use this to eliminate this possibility?
Jon.
On Saturday, August 24, 2019, 09:17:22 AM PDT, Mike Schwab
wrote:
> Well, keys a
t; They are supposed to be uniquely paired.
> "Supposed to be." Is that real different from what I said?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jon Perryman
Sent: Saturday, August 24, 2019 7:40 AM
To: IBM-MAIN@
Saturday, August 24, 2019 11:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key
PGP allows sending encrypted emails/data to multiple recipients, where
each recipient has a different private key, and this works AOK (but no
idea how). I have 'PGP Desktop Whole D
On Aug 24, 2019, at 11:16 AM, Mike Schwab wrote:
>
> Well, keys are supposed to be two large prime numbers. Without a
> registry of which numbers have been used, it would be possible for two
> people to use the same prime number.
RSA keys are *generated* from two large prime numbers, but the ke
2019 8:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: vendor distributes their private key
>
> The vendor can revoke his private/public key, generate a new
> private/public key pair and - hopefully this time - publish only the
> public key.
>
> BTW I believe a public ke
On Sat, 24 Aug 2019 11:16:57 -0500, Mike Schwab wrote:
>Well, keys are supposed to be two large prime numbers. Without a
>registry of which numbers have been used, it would be possible for two
>people to use the same prime number.
>
Such a registry would defeat the purpose, although a registry of
Well, keys are supposed to be two large prime numbers. Without a
registry of which numbers have been used, it would be possible for two
people to use the same prime number.
On Sat, Aug 24, 2019 at 9:40 AM Jon Perryman wrote:
>
>
>
> On Friday, August 23, 2019, 04:34:14 PM PDT, Charles Mills
fferent from what I said?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jon Perryman
Sent: Saturday, August 24, 2019 7:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key
On Friday, A
On Friday, August 23, 2019, 04:34:14 PM PDT, Charles Mills
wrote:
>> I believe a public key can be associated with more than one PGP private key
> I don't know PGP at all but for basic asymmetrical or public/private key
> encryption,
> the public and private keys are basically one to
IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key
The vendor can revoke his private/public key, generate a new
private/public key pair and - hopefully this time - publish only the
public key.
BTW I believe a public key can be associated with more than one PGP
private key, although
On Thu, 22 Aug 2019 at 22:47, Kirk Wolf wrote:
> BUT: if this vendor is giving you its server's private key, then the server
> is *not* secure. This is because when you connect to that server you don't
> know if you are really talking to the vendor or someone else, since anyone
> with the privat
The vendor can revoke his private/public key, generate a new
private/public key pair and - hopefully this time - publish only the
public key.
BTW I believe a public key can be associated with more than one PGP
private key, although doing so would still not explain the vendor's
publishing a privat
inframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Thursday, August 22, 2019 12:42 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: vendor distributes their private key
>
> On Thu, 22 Aug 2019 14:13:58 -0500, Joel M Ivey wrote:
>
>
Certificate key.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Thursday, August 22, 2019 12:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key
On Thu, 22 Aug 2019 14
> what I'm missing as to why any vendor would require me to install their
> private key on my side
You don't read Dilbert, do you? If it were me I'd be looking for a different
vendor.
> their response has essentially been, that's the way we do it.
Run, do not walk, to the nearest exit.
--
Sh
On Thu, 22 Aug 2019 14:13:58 -0500, Joel M Ivey wrote:
>Thanks all for the response. I'm glad I wasn't missing something. I will
>discuss further with the vendor, hoping they will recognize the risks.
>
How can the vendor recover from this without causing great
disruption, even an indefinite
Thanks all for the response. I'm glad I wasn't missing something. I will
discuss further with the vendor, hoping they will recognize the risks.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
ainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jon Perryman
Sent: Thursday, August 22, 2019 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key
Ask yourself if you can trust a vendor that does not understand basic security
concepts.
Ask yourself if you can trust a vendor that does not understand basic security
concepts. When you complain, will they simply give you the public key or will
they request new public / private keys? I personally would be leery because
they will be make much worse mistakes.
The standard helps with
ent: Thursday, August 22, 2019 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key
On Thu, 22 Aug 2019 at 11:06, Charles Mills wrote:
> You might ask what part of *private* key they are having trouble
> understanding.
See "Why Johnny Can't En
] On Behalf
Of Charles Mills
Sent: Thursday, August 22, 2019 8:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key
Joel, it's just plain wrong. Others have listed the specifics. It just plain
shows they have no clue how certificates work. It would be like i
On Thu, 22 Aug 2019 at 11:06, Charles Mills wrote:
> You might ask what part of *private* key they are having trouble
> understanding.
See "Why Johnny Can't Encrypt" (1999)
https://pdfs.semanticscholar.org/389f/55c5c376db4ce1c88161dca98c329614faa8.pdf
and "Why Johnny Still Can't Encrypt" (2016)
Joel, it's just plain wrong. Others have listed the specifics. It just plain
shows they have no clue how certificates work. It would be like if you
installed a nice lock on your front door, and then hung the key on a hook
outside next to it.
You might ask what part of *private* key they are ha
On Thu, Aug 22, 2019 at 9:03 AM Mike Wawiorko <
014ab5cdfb21-dmarc-requ...@listserv.ua.edu> wrote:
> Private keys should be locked away and treated like the company's crown
> jewels. If you have their private key it is likely many other sites also
> have.
>
I imagine that company also posts a
Private keys should be locked away and treated like the company's crown jewels.
If you have their private key it is likely many other sites also have.
That renders their site completely untrustworthy. I would not send anything
confidential or, arguably, anything at all to that site.
On the oth
The best argument is impersomating. Anone holding the private ket can
present himself like the vendor. The risk is that if you download code form
this vendor, you might download agresive code form someone pretending to be
the vendor.
ITschak
On Thu, Aug 22, 2019 at 3:57 PM Joel M Ivey wrote:
>
61 matches
Mail list logo
