Some may remember Bleichenbacher found a random number generator bias in the
original DSA spec, that could leak the key after soem number of signatures
depending the circumstances.
Its described in this summary of DSA issues by Vaudenay Evaluation Report
on DSA
The problem with offensive cyberwarfare is that, given the imbalance between
attackers and defenders and the expanding use of computer controls in all sorts
of systems, a cyber war between two advanced countries will not decide anything
militarily, but will leave both combattants much poorer
Just thinking out loud
The administrative complexity of a cryptosystem is overwhelmingly in key
management and identity management and all the rest of that stuff. So imagine
that we have a widely-used inner-level protocol that can use strong crypto, but
also requires no external key
On 10/9/13 at 7:18 PM, crypto@gmail.com (John Kelsey) wrote:
We know how to address one part of this problem--choose only
algorithms whose design strength is large enough that there's
not some relatively close by time when the algorithms will need
to be swapped out. That's not all that
2013/10/9 Phillip Hallam-Baker hal...@gmail.com
I see cyber-sabotage as being similar to use of chemical or biological
weapons: It is going to be banned because the military consequences fall
far short of being decisive, are unpredictable and the barriers to entry
are low.
I doubt that's
2013/10/10 Phillip Hallam-Baker hal...@gmail.com
The original author was proposing to use the same key for encryption and
signature which is a rather bad idea.
Explain why, please. It might expand the attack surface, that's true. You
could always add a signed message that says I used a key
On 10/9/13 at 7:12 PM, watsonbl...@gmail.com (Watson Ladd) wrote:
On Tue, Oct 8, 2013 at 1:46 PM, Bill Frantz fra...@pwpconsult.com wrote:
... As professionals, we have an obligation to share our
knowledge of the limits of our technology with the people who
are depending on it. We know that
Watson Ladd watsonbl...@gmail.com writes:
The obvious solution: Do it right the first time.
And how do you know that you're doing it right? PGP in 1992 adopted a
bleeding-edge cipher (IDEA) and was incredibly lucky that it's stayed secure
since then. What new cipher introduced up until 1992
TLS was designed to support multiple ciphersuites. Unfortunately this opened
the door
to downgrade attacks, and transitioning to protocol versions that wouldn't do
this was nontrivial.
The ciphersuites included all shared certain misfeatures, leading to the
current situation.
On the
Very silly but trivial to implement so I went ahead and did so:
To send a prism-proof email, encrypt it for your recipient and send it
to irrefrangi...@mail.unipay.nl. Don't include any information about
the recipient, just send the ciphertext (in some form of ascii armor).
Be sure to include
2013/10/10 John Kelsey crypto@gmail.com
The problem with offensive cyberwarfare is that, given the imbalance
between attackers and defenders and the expanding use of computer controls
in all sorts of systems, a cyber war between two advanced countries will
not decide anything militarily,
I sarcastically proposed the use of GOST as an alternative to NIST crypto.
Someone shot back a note saying the elliptic curves might be 'bent'.
Might be interesting for EC to take another look at GOST since it might be
the case that the GRU and the NSA both found a similar backdoor but one was
Having a public bulletin board of posted emails, plus a protocol for
anonymously finding the ones your key can decrypt, seems like a pretty decent
architecture for prism-proof email. The tricky bit of crypto is in making
access to the bulletin board both efficient and private.
--John
On 10 Oct 2013, at 17:06, John Kelsey crypto@gmail.com wrote:
Just thinking out loud
The administrative complexity of a cryptosystem is overwhelmingly in key
management and identity management and all the rest of that stuff. So
imagine that we have a widely-used inner-level
The simple(-minded) idea is that everybody receives everybody's email, but
can only read their own. Since everybody gets everything, the metadata is
uninteresting and traffic analysis is largely fruitless.
Some traffic analysis is still possible based on just message originator. If I
see
On Oct 10, 2013, at 11:58 AM, R. Hirschfeld r...@unipay.nl wrote:
Very silly but trivial to implement so I went ahead and did so:
To send a prism-proof email, encrypt it for your recipient and send it
to irrefrangi...@mail.unipay.nl
Nice! I like it.
A couple of comments:
1. Obviously,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Cool.
Drop me a note if you want hosting (gratis) for this.
On 10/10/13 10:22 PM, Jerry Leichter wrote:
On Oct 10, 2013, at 11:58 AM, R. Hirschfeld r...@unipay.nl
wrote:
Very silly but trivial to implement so I went ahead and did
so:
To send
Having a public bulletin board of posted emails, plus a protocol
for anonymously finding the ones your key can decrypt, seems
like a pretty decent architecture for prism-proof email.
The tricky bit of crypto is in making access to the bulletin
board both efficient and private.
This idea has
More random thoughts:
The minimal inner protocol would be something like this:
Using AES-CCM with a tag size of 32 bits, IVs constructed based on an implicit
counter, and an AES-CMAC-based KDF, we do the following:
Sender:
a. Generate random 128 bit value R
b. Use the KDF to compute
On 2013-10-10 (283), at 15:29:33, Stephen Farrell stephen.farr...@cs.tcd.ie
wrote:
On 10 Oct 2013, at 17:06, John Kelsey crypto@gmail.com wrote:
Just thinking out loud
[]
c. Both sides derive the shared key abG, and then use SHAKE512(abG) to
generate an AES key for
On 10/10/2013 12:54 PM, John Kelsey wrote:
Having a public bulletin board of posted emails, plus a protocol
for anonymously finding the ones your key can decrypt, seems
like a pretty decent architecture for prism-proof email. The
tricky bit of crypto is in making access to the bulletin
Does PGP have any particular support for key signing parties built in or is
this just something that has grown up as a practice of use?
It's just a practice. I agree that building a small amount of automation
for key signing parties would improve the web of trust.
I have started on a
On Oct 10, 2013, at 5:15 PM, Richard Outerbridge ou...@sympatico.ca wrote:
How does this prevent MITM? Where does G come from?
I'm assuming G is a systemwide shared parameter. It doesn't prevent
mitm--remember the idea here is to make a fairly lightweight protocol to run
*inside* another
On Oct 10, 2013, at 5:20 PM, Ray Dillinger b...@sonic.net wrote:
On 10/10/2013 12:54 PM, John Kelsey wrote:
Having a public bulletin board of posted emails, plus a protocol
for anonymously finding the ones your key can decrypt, seems
like a pretty decent architecture for prism-proof email.
John,
On Oct 10, 2013, at 2:31 PM, John Gilmore wrote:
An important user experience point is that we should be teaching GPG
users to only sign the keys of people who they personally know.
Having a signature that says, This person attended the RSA conference
in October 2013 is not
On 10/10/2013 02:20 PM, Ray Dillinger wrote:
split the message stream
into channels when it gets to be more than, say, 2GB per day.
That's fine, in the case where the traffic is heavy.
We should also discuss the opposite case:
*) If the traffic is light, the servers should generate cover
On Thu, Oct 10, 2013 at 11:58 AM, R. Hirschfeld r...@unipay.nl wrote:
To send a prism-proof email, encrypt it for your recipient and send it
to irrefrangi...@mail.unipay.nl. Don't include any information about
To receive prism-proof email, subscribe to the irrefrangible mailing
list at
On Thu, 2013-10-10 at 14:20 -0700, Ray Dillinger wrote:
Wrong on both counts, I think. If you make access private, you
generate metadata because nobody can get at mail other than their
own. If you make access efficient, you generate metadata because
you're avoiding the wasted bandwidth that
On Oct 10, 2013, at 2:31 PM, John Gilmore g...@toad.com wrote:
Does PGP have any particular support for key signing parties built in or is
this just something that has grown up as a practice of use?
It's just a practice. I agree that building a small amount of automation
for key signing
On Thu, Oct 10, 2013 at 3:32 PM, John Kelsey crypto@gmail.com wrote:
The goal is to have an inner protocol which can run inside TLS or some
similar thing
[...]
Suppose we have this inner protocol running inside a TLS version that is
subject to one of the CBC padding reaction attacks.
Thursday, October 10, 2013, Phillip Hallam-Baker wrote:
[Can't link to FIPS180-4 right now as its down]
For the lazy among us, including my future self, a shutdown-proof url to
the archive.org copy of the NIST FIPS 180-4 pdf:
http://tinyurl.com/FIPS180-4
-David Mercer
--
David Mercer
On Thursday, October 10, 2013, Salz, Rich wrote:
TLS was designed to support multiple ciphersuites. Unfortunately this
opened the door
to downgrade attacks, and transitioning to protocol versions that
wouldn't do this was nontrivial.
The ciphersuites included all shared certain
32 matches
Mail list logo
