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 $1/mo
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
> 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 /dev/rando
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
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 i
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.
>
>>
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* feedb
* John Denker [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 accuses
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 is
> 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
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 ridic
On 10/11/2013 11:23 AM, Wouter Slegers wrote:
> Dear Ray,
>
> On 2013-10-11, at 19:38 , 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
Stephen Farrell
wrote:
>
> 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
On Oct 12, 2013, at 6:51 AM, Ben Laurie 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 vulnerable to
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
On 10 October 2013 17:06, 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 s
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
On 10/11/13 7:34 PM, Peter Gutmann wrote:
Phillip Hallam-Baker writes:
Quick question, anyone got a good scheme for key stretching?
http://lmgtfy.com/?q=hkdf&l=1
Yeah, that's a weaker simplification of the method I've always
advocated, stopping the hash function before the final
MD-strengt
Tim Hudson 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 a safer value lik
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
Phillip Hallam-Baker writes:
>Quick question, anyone got a good scheme for key stretching?
http://lmgtfy.com/?q=hkdf&l=1
Peter :-).
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
Hi,
commented:
#An alternative I've been considering is having e-mail clients support
#bouncing messages if they are received for an incorrect envelope
#address. So you can have an envelope address and a PGP encrypted blob,
#and when you decrypt that blob there's a new RFC822 with a new envel
On Fri, Oct 11, 2013 at 10:32 AM, Zooko O'Whielacronx 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 the "higher
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
arti
On Oct 11, 2013, at 11:26 AM, Phillip Hallam-Baker 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 for this but
Dear Ray,
On 2013-10-11, at 19:38 , 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
On 2013-10-11, at 07:03, Tony Naggs wrote:
> On 10 October 2013 22:31, John Gilmore 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
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, w
AES128, rather.
Sent from my iPhone
On Oct 11, 2013, at 11:26 AM, Phillip Hallam-Baker wrote:
> All,
>
> 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.
>
> AES
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
http://www.metz
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 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 would
On 10/10/2013 08: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
On Thu, Oct 10, 2013 at 04:22:50PM -0400, Jerry Leichter wrote:
> On Oct 10, 2013, at 11:58 AM, "R. Hirschfeld" 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.uni
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 wo
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 t
grarpamp wrote:
> On Thu, Oct 10, 2013 at 11:58 AM, R. Hirschfeld 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 mailin
Glenn Willen writes:
>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, and completely ignoring personal knowledge
On 11/10/13 02:24 AM, Glenn Willen wrote:
John,
On Oct 10, 2013, at 2:31 PM, John Gilmore wrote:
... Signing them would assert to
any stranger that "I know that this key belongs to this identity", which
would be false and would undermine the strength of the web of trust.
Where is this writ
On 2013-10-10 (283), at 19:24:19, Glenn Willen 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 and would u
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 RSA
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 crypto
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 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
-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 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
>>
On Oct 11, 2013, at 1:48 AM, ianG 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 protocol problems
-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
wj8DBQFSWDC65/HCKu9Iqw
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 mis
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 Merce
On Thu, Oct 10, 2013 at 3:32 PM, John Kelsey 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. The inner protoc
On Oct 10, 2013, at 2:31 PM, John Gilmore 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 w
On Thu, Oct 10, 2013 at 11:58 AM, R. Hirschfeld 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 http://mail.uni
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
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 tr
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 part
On Oct 10, 2013, at 5:20 PM, Ray Dillinger 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. The
>>
On Oct 10, 2013, at 5:15 PM, Richard Outerbridge 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 crypto protocol li
> 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 prototy
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
On 2013-10-10 (283), at 15:29:33, Stephen Farrell
wrote:
>> On 10 Oct 2013, at 17:06, John Kelsey wrote:
>>
>> Just thinking out loud
>>
[]
>> c. Both sides derive the shared key abG, and then use SHAKE512(abG) to
>> generate an AES key for messages in each direction.
How does th
> 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
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 K[S],N[S
-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"
> wrote:
>> Very silly but trivial to "implement" so I went ahead and did
>> so:
>>
>> To send a
> 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
se
On Oct 10, 2013, at 11:58 AM, "R. Hirschfeld" 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, this h
> On 10 Oct 2013, at 17:06, 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 c
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
___
2013/10/10 John Kelsey
> 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 bo
> 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
Watson Ladd 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 has had that
distinctio
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 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 all crypto standards wh
2013/10/10 Phillip Hallam-Baker
> 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 named 'Z' for
2013/10/9 Phillip Hallam-Baker
> 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 anywhere near
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 bi
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 manage
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 tha
On Oct 8, 2013, at 4:46 PM, Bill Frantz 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 that all
> crypto s
On Tue, Oct 8, 2013 at 1:46 PM, Bill Frantz 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 wrote:
>
>
>>> We seriously need to consider what the design lifespan of our crypto suites
>>> is in real life. That data should be
On Tue, Oct 8, 2013 at 4:14 PM, James A. Donald 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 elliptic p
> 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 sa
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 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 va
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.
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 Oct 7, 2013, at 12:55 PM, Jerry Leichter wrote:
> On Oct 7, 2013, at 11:45 AM, Arnold Reinhold 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 key s
On 10/8/13 at 7:38 AM, leich...@lrw.com (Jerry Leichter) wrote:
On Oct 8, 2013, at 1:11 AM, Bill Frantz 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 designers so they know
what
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 Wed, Oct 9, 2013 at 12:44 AM, Tim Newsham 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 today, whereas
>
On Tue, Oct 8, 2013 at 7:38 AM, Jerry Leichter wrote:
> On Oct 8, 2013, at 1:11 AM, Bill Frantz 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 so
On Mon, 7 Oct 2013 10:54:50 +0200
Lay András 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 curve
>
On Oct 8, 2013, at 1:11 AM, Bill Frantz 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 that pre
Le 7 oct. 2013 à 17:45, Arnold Reinhold 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.
- The size o
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 t
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 essen
On 10/6/2013 12:17 PM, Salz, Rich wrote:
Last week, the American TV show Elementary (a TV who-done-it) was
about the murder of two mathematicians who were working on proof of
P=NP. The implications to crypto, and being able to "crack into
servers" was covered. It was mostly accurate, up until
On Oct 7, 2013, at 1:43 AM, Peter Gutmann wrote:
> Given the recent debate about security levels for different key sizes, the
> following paper by Lenstra, Kleinjung, and Thome may be of interest:
>
> "Universal security from bits and mips to pools, lakes and beyond"
> http://eprint.iacr.org/201
On 07.10.2013 10:54, Lay András 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 curve
> cryptography,
On Sun, Oct 6, 2013 at 11:26 AM, 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 that pret
On Oct 7, 2013, at 6:04 PM, "Philipp Gühring" wrote:
>> it makes no sense for a hash function: If the attacker can specify
>> something about the input, he ... knows something about the input!
> Yes, but since it's standardized, it's public knowledge, and just knowing
> the padding does not giv
On Oct 7, 2013, at 12:45 PM, Ray Dillinger wrote:
> Can we do anything ...[to make it possible to remove old algorithms]? If the
> protocol allows correction (particularly remote or automated correction) of
> an entity using a weak crypto primitive, that opens up a whole new set of
> attacks on
On Mon, Oct 7, 2013 at 4:54 AM, Lay András wrote:
> Hi!
>
> 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 curv
1 - 100 of 10377 matches
Mail list logo
