On 14/10/2013 14:36, Eugen Leitl wrote:
Guys, in order to minimize Tor Project's dependance on
federal funding and/or increase what they can do it
would be great to have some additional funding ~10 kUSD/month.
I would say what is needed is not one source at $10K/month but 10K
sources at
On Tue, Oct 01, 2013 at 12:47:56PM -0400, John Kelsey wrote:
The actual technical question is whether an across the board 128 bit
security level is sufficient for a hash function with a 256 bit output.
This weakens the proposed SHA3-256 relative to SHA256 in preimage
resistance, where SHA256
* John Denker j...@av8n.com [2013-10-10 17:13 -0700]:
*) Each server should publish a public key for /dev/null so that
users can send cover traffic upstream to the server, without
worrying that it might waste downstream bandwidth.
This is crucial for deniabililty: If the rubber-hose guy
Adam,
I guess I should preface this by saying I am speaking only for myself. That's
always true here--it's why I'm using my personal email address. But in
particular, right now, I'm not *allowed* to work. But just speaking my own
personal take on things
We go pretty *overwhelming*
On Oct 13, 2013, at 1:04 PM, Ray Dillinger wrote:
This is despite meeting (for some inscrutable definition of meeting)
FIPS 140-2 Level 2 and Common Criteria standards. These standards
require steps that were clearly not done here. Yet, validation
certificates were issued.
This is a
On 14/10/13 17:51 PM, Adam Back wrote:
On Tue, Oct 01, 2013 at 12:47:56PM -0400, John Kelsey wrote:
The actual technical question is whether an across the board 128 bit
security level is sufficient for a hash function with a 256 bit
output. This weakens the proposed SHA3-256 relative to SHA256
On Tue, Oct 15, 2013 at 12:35:13AM -, d...@deadhat.com wrote:
http://eprint.iacr.org/2013/338.pdf
*LINUX* /dev/random is not robust, so claims the paper.
I wonder how various *BSDs or the Solarish family (Illumos, Oracle Solaris)
hold up under similar scrutiny?
Linux is big, but it is not
http://eprint.iacr.org/2013/338.pdf
I'll be the first to admit that I don't understand this paper. I'm
just an engineer, not a mathematician. But it looks to me like the
authors are academics, who create an imaginary construction method for
a random number generator, then prove that
On 2013-10-15 10:35, d...@deadhat.com wrote:
http://eprint.iacr.org/2013/338.pdf
No kidding.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
On 10/11/2013 11:22 AM, Jerry Leichter wrote:
1. Brute force. No public key-stretching algorithm can help, since the
attacker
will brute-force the k's, computing the corresponding K's as he goes.
There is a completely impractical solution for this which is applicable
in a very few
Without doing any key management or requiring some kind of reliable
identity or memory of previous sessions, the best we can do in the inner
protocol is an ephemeral Diffie-Hellman, so suppose we do this:
a. Generate random a and send aG on curve P256
b. Generate random b and send bG on
On 2013-10-11 15:48, ianG wrote:
Right now we've got a TCP startup, and a TLS startup. It's pretty
messy. Adding another startup inside isn't likely to gain popularity.
The problem is that layering creates round trips, and as cpus get ever
faster, and pipes ever fatter, round trips become a
Tim Hudson t...@cryptsoft.com writes:
Does anyone recollect the history behind and the implications of the (open)
SSH choice of 35 as a hard-wired public exponent?
/* OpenSSH versions up to 5.4 (released in 2010) hardcoded e = 35, which is
both a suboptimal exponent (it's less efficient that
On 10/11/13 7:34 PM, Peter Gutmann wrote:
Phillip Hallam-Baker hal...@gmail.com writes:
Quick question, anyone got a good scheme for key stretching?
http://lmgtfy.com/?q=hkdfl=1
Yeah, that's a weaker simplification of the method I've always
advocated, stopping the hash function before the
On 10 October 2013 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
On Oct 11, 2013, at 11:09 PM, James A. Donald wrote:
Right now we've got a TCP startup, and a TLS startup. It's pretty messy.
Adding another startup inside isn't likely to gain popularity.
The problem is that layering creates round trips, and as cpus get ever
faster, and pipes ever
If someone wants to try organise a pgp key signing party at
the Vancouver IETF next month let me know and I can organise a
room/time. That's tended not to happen since Ted and Jeff
don't come along but we could re-start 'em if there's interest.
S
On Oct 12, 2013, at 6:51 AM, Ben Laurie b...@links.org wrote:
...
AIUI, you're trying to make it so that only active attacks work on the
combined protocol, whereas passive attacks might work on the outer
protocol. In order to achieve this, you assume that your proposed
inner protocol is not
stephen.farr...@cs.tcd.iewrote:
If someone wants to try organise a pgp key signing party at
the Vancouver IETF next month let me know and I can organise a
room/time. That's tended not to happen since Ted and Jeff
don't come along but we could re-start 'em if there's interest.
S
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I think this thread has run its course and is sufficiently off topic for this
list, so I am declaring it closed.
Thank you
Tamzen
-BEGIN PGP SIGNATURE-
Version: PGP Universal 3.2.0 (Build 1672)
Charset: us-ascii
On Oct 11, 2013, at 1:48 AM, ianG i...@iang.org wrote:
...
What's your goal? I would say you could do this if the goal was ultimate
security. But for most purposes this is overkill (and I'd include online
banking, etc, in that).
We were talking about how hard it is to solve crypto
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/10/2013 6:40 PM, grarpamp wrote: 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
On Thu, Oct 10, 2013 at 03:54:26PM -0400, 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
On Thu, Oct 10, 2013 at 04:24:19PM -0700, Glenn Willen wrote:
I am going to be interested to hear what the rest of the list says about
this, because this definitely contradicts what has been presented to me as
'standard practice' for PGP use -- verifying identity using government issued
ID,
On 10/10/13 19:06 PM, John Kelsey 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 protocol that can use strong
Reply to various,
Yes, the value in a given key signing is weak, in fact every link in the
web of trust is terribly weak.
However, if you notarize and publish the links in CT fashion then I can
show that they actually become very strong. I might not have good evidence
of John Gilmore's key at
On 2013-10-10 (283), at 19:24:19, Glenn Willen gwil...@nerdnet.org wrote:
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.
[]
would be false
grarpamp wrote:
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
On 10/10/13 08:41 AM, Bill Frantz wrote:
We should try to characterize what a very long time is in years. :-)
Look at the produce life cycle for known crypto products. We have some
experience of this now. Skype, SSL v2/3 - TLS 0/1/2, SSH 1 - 2, PGP 2
- 5+.
As a starting point, I would
On 10/10/13 17:58 PM, 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 misfeatures, leading to
On Thu, Oct 10, 2013 at 04:22:50PM -0400, 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 a prism-proof email, encrypt it for your recipient and send it
to
I like the ideas, John.
The idea, and the protocol you sketched out, are a little reminiscent
of ZRTP ¹ and of tcpcrypt ². I think you can go one step further,
however, and make it *really* strong, which is to offer the higher
or outer layer a way to hook into the crypto from your inner layer.
On 10 October 2013 22:31, 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 parties
This is a job for a key derivation function or a cryptographic prng. I would
use CTR-DRBG from 800-90 with AES256. Or the extract-then-expand KDF based on
HMAC-SHA512.
--John
___
The cryptography mailing list
cryptography@metzdowd.com
On 10/11/13 at 10:32 AM, zoo...@gmail.com (Zooko O'Whielacronx) wrote:
Don't try to study
foolscap, even though it is a very interesting practical approach,
because there doesn't exist documentation of the protocol at the right
level for you to learn from.
Look at the E language sturdy refs,
On 2013-10-11, at 07:03, Tony Naggs tonyna...@gmail.com wrote:
On 10 October 2013 22:31, 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
On Oct 11, 2013, at 11:26 AM, Phillip Hallam-Baker hal...@gmail.com wrote:
Quick question, anyone got a good scheme for key stretching?
I have this scheme for managing private keys that involves storing them as
encrypted PKCS#8 blobs in the cloud.
AES128 seems a little on the weak side
Dear Ray,
On 2013-10-11, at 19:38 , Ray Dillinger b...@sonic.net wrote:
This is despite meeting (for some inscrutable definition of meeting)
FIPS 140-2 Level 2 and Common Criteria standards. These standards
require steps that were clearly not done here. Yet, validation
certificates were
On 2013-10-11 12:03:44 +0100 (+0100), Tony Naggs wrote:
Do key signing parties even happen much anymore? The last time I saw
one advertised was around PGP 2.6!
[...]
Within more active pockets of the global free software community
(where OpenPGP signatures are used to authenticate release
On Fri, Oct 11, 2013 at 10:32 AM, Zooko O'Whielacronx zoo...@gmail.com wrote:
I like the ideas, John.
The idea, and the protocol you sketched out, are a little reminiscent
of ZRTP ¹ and of tcpcrypt ². I think you can go one step further,
however, and make it *really* strong, which is to offer
Phillip Hallam-Baker hal...@gmail.com writes:
Quick question, anyone got a good scheme for key stretching?
http://lmgtfy.com/?q=hkdfl=1
Peter :-).
___
The cryptography mailing list
cryptography@metzdowd.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, 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
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,
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
On Tue, Oct 8, 2013 at 7:38 AM, Jerry Leichter leich...@lrw.com wrote:
On Oct 8, 2013, at 1:11 AM, Bill Frantz fra...@pwpconsult.com wrote:
If we can't select ciphersuites that we are sure we will always be
comfortable with (for at least some forseeable lifetime) then we urgently
need the
On Wed, Oct 9, 2013 at 12:44 AM, Tim Newsham tim.news...@gmail.com wrote:
We are more vulnerable to widespread acceptance of these bad principles
than
almost anyone, ultimately, But doing all these things has won larger
budgets
and temporary successes for specific people and agencies
On 2013-10-08 03:14, Phillip Hallam-Baker wrote:
Are you planning to publish your signing key or your decryption key?
Use of a key for one makes the other incompatible.�
Incorrect. One's public key is always an elliptic point, one's private
key is always a number.
Thus there is no reason
On 10/8/13 at 7:38 AM, leich...@lrw.com (Jerry Leichter) wrote:
On Oct 8, 2013, at 1:11 AM, Bill Frantz fra...@pwpconsult.com wrote:
We seriously need to consider what the design lifespan of our
crypto suites is in real life. That data should be
communicated to hardware and software
On Oct 7, 2013, at 12:55 PM, Jerry Leichter wrote:
On Oct 7, 2013, at 11:45 AM, Arnold Reinhold a...@me.com wrote:
If we are going to always use a construction like AES(KDF(key)), as Nico
suggests, why not go further and use a KDF with variable length output like
Keccak to replace the AES
On 2013-10-08 02:03, John Kelsey wrote:
Alongside Phillip's comments, I'll just point out that assassination of key
people is a tactic that the US and Israel probably don't have any particular
advantages in. It isn't in our interests to encourage a worldwide tacit
acceptance of that stuff.
On 10/07/2013 05:28 PM, David Johnston wrote:
We are led to believe that if it is shown that P = NP, we suddenly have a
break for all sorts of algorithms.
So if P really does = NP, we can just assume P = NP and the breaks will make
themselves evident. They do not. Hence P != NP.
As
On Oct 8, 2013, at 6:10 PM, Arnold Reinhold wrote:
On Oct 7, 2013, at 12:55 PM, Jerry Leichter wrote:
On Oct 7, 2013, at 11:45 AM, Arnold Reinhold a...@me.com wrote:
If we are going to always use a construction like AES(KDF(key)), as Nico
suggests, why not go further and use a KDF with
We are more vulnerable to widespread acceptance of these bad principles than
almost anyone, ultimately, But doing all these things has won larger budgets
and temporary successes for specific people and agencies today, whereas
the costs of all this will land on us all in the future.
The same
On Tue, Oct 8, 2013 at 4:14 PM, James A. Donald jam...@echeque.com wrote:
On 2013-10-08 03:14, Phillip Hallam-Baker wrote:
Are you planning to publish your signing key or your decryption key?
Use of a key for one makes the other incompatible.�
Incorrect. One's public key is always an
On Tue, Oct 8, 2013 at 1:46 PM, Bill Frantz fra...@pwpconsult.com wrote:
On 10/8/13 at 7:38 AM, leich...@lrw.com (Jerry Leichter) wrote:
On Oct 8, 2013, at 1:11 AM, Bill Frantz fra...@pwpconsult.com wrote:
We seriously need to consider what the design lifespan of our crypto suites
is in
On Oct 8, 2013, at 4:46 PM, Bill Frantz fra...@pwpconsult.com wrote:
I think the situation is much more serious than this comment makes it appear.
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
On 10/6/13 at 8:26 AM, crypto@gmail.com (John Kelsey) wrote:
If we can't select ciphersuites that we are sure we will always
be comfortable with (for at least some forseeable lifetime)
then we urgently need the ability to *stop* using them at some
point. The examples of MD5 and RC4 make
On Oct 4, 2013, at 12:20 PM, Ray Dillinger wrote:
So, it seems that instead of AES256(key) the cipher in practice should be
AES256(SHA256(key)).
Is it not the case that (assuming SHA256 is not broken) this
defines a cipher
effectively immune to the related-key attack?
So you're
Le 7 oct. 2013 à 17:45, Arnold Reinhold a...@me.com a écrit :
other cipher algorithms are unlikely to catch up in performance in the
foreseeable future
You should take a look a this algorithm : http://eprint.iacr.org/2013/551.pdf
- The block size is variable and unknown from an attacker.
-
On Oct 8, 2013, at 1:11 AM, Bill Frantz fra...@pwpconsult.com wrote:
If we can't select ciphersuites that we are sure we will always be
comfortable with (for at least some forseeable lifetime) then we urgently
need the ability to *stop* using them at some point. The examples of MD5
and RC4
On Mon, 7 Oct 2013 10:54:50 +0200
Lay András and...@lay.hu wrote:
I made a simple elliptic curve utility in command line PHP:
https://github.com/LaySoft/ecc_phgp
I know in the RSA, the sign is inverse operation of encrypt, so two
different keypairs needs for encrypt and sign. In elliptic
On Sat, Oct 05, 2013 at 09:29:05PM -0400, John Kelsey wrote:
One thing that seems clear to me: When you talk about algorithm
flexibility in a protocol or product, most people think you are
talking about the ability to add algorithms. Really, you are talking
more about the ability to *remove*
On Sat, Oct 5, 2013 at 7:36 PM, James A. Donald jam...@echeque.com wrote:
On 2013-10-04 23:57, Phillip Hallam-Baker wrote:
Oh and it seems that someone has murdered the head of the IRG cyber
effort. I condemn it without qualification.
I endorse it without qualification. The IRG are bad
On 10/04/2013 07:38 AM, Jerry Leichter wrote:
On Oct 1, 2013, at 5:34 AM, Ray Dillinger b...@sonic.net wrote:
What I don't understand here is why the process of selecting a standard
algorithm for cryptographic primitives is so highly focused on speed.
If you're going to choose a single
On 2013-10-07 01:18, Phillip Hallam-Baker wrote:
We are not at war with Iran.
We are not exactly at peace with Iran either, but that is irrelevant,
for presumably it was a Jew that did it, and Iran is at war with Jews.
(And they are none too keen on Christians, Bahais, or Zoroastrians
On Oct 5, 2013, at 6:12 PM, Ben Laurie wrote:
I have to take issue with this:
The security is not reduced by adding these suffixes, as this is only
restricting the input space compared to the original Keccak. If there
is no security problem on Keccak(M), there is no security problem on
On Oct 5, 2013, at 9:29 PM, John Kelsey wrote:
One thing that seems clear to me: When you talk about algorithm flexibility
in a protocol or product, most people think you are talking about the ability
to add algorithms. Really, you are talking more about the ability to
*remove*
On Thu, Oct 3, 2013 at 12:21 PM, Jerry Leichter leich...@lrw.com wrote:
On Oct 3, 2013, at 10:09 AM, Brian Gladman b...@gladman.plus.com wrote:
Leaving aside the question of whether anyone weakened it, is it
true that AES-256 provides comparable security to AES-128?
I may be wrong about
On Oct 6, 2013, at 6:29 PM, Jerry Leichter leich...@lrw.com wrote:
On Oct 5, 2013, at 6:12 PM, Ben Laurie wrote:
I have to take issue with this:
The security is not reduced by adding these suffixes, as this is only
restricting the input space compared to the original Keccak. If there
is no
Is it just me, or does the government really have absolutely no one
with any sense of irony? Nor, increasingly, anyone with a sense of
shame?
I have to ask, because after directly suborning the cyber security
of most of the world including the USA, and destroying the credibility
of just about
On Oct 6, 2013, at 11:41 PM, John Kelsey wrote:
...They're making this argument by pointing out that you could simply stick
the fixed extra padding bits on the end of a message you processed with the
original Keccak spec, and you would get the same result as what they are
doing. So if
On 05/10/13 20:00, John Kelsey wrote:
http://keccak.noekeon.org/yes_this_is_keccak.html
Seems the Keccac people take the position that Keccak is actually a way
of creating hash functions, rather than a specific hash function - the
created functions may be ridiculously strong, or far too
On 05/10/13 00:09, Dan Kaminsky wrote:
Because not being fast enough means you don't ship. You don't ship, you
didn't secure anything.
Performance will in fact trump security. This is the empirical reality.
There's some budget for performance loss. But we have lots and lots of
slow
On Sun, Oct 6, 2013 at 9:10 PM, Phillip Hallam-Baker hal...@gmail.com wrote:
I am even
starting to think that maybe we should start using the NSA checksum
approach.
Incidentally, that checksum could be explained simply by padding prepping an
EC encrypted session key. PKCS#1 has similar stuff
1 - 100 of 8089 matches
Mail list logo
