On Tue, Sep 10, 2013 at 10:59 PM, William Allen Simpson
william.allen.simp...@gmail.com wrote:
I suggest:
ChaCha20 is run with the given key and sequence number nonce and with
the two counter words set to zero. The first 32 bytes of the 64 byte
output are saved to become the
[attempt two, because I bounced off the mailing list the first time.]
On Tue, Sep 10, 2013 at 9:35 PM, William Allen Simpson
william.allen.simp...@gmail.com wrote:
ChaCha20 is run with the given key and nonce and with the two counter
words set to zero. The first 32 bytes of the 64 byte
Gentlefolk,
Fingerprint scanners have shipped on laptops and phones for years.
Yesterday, Apple made the bold, unaudited claim that it will never save
the fingerprint data outside of the A7 chip.
Why should we trust Cook Co.? They are subject to the laws of the
land
On Tue, Sep 10, 2013 at 09:01:49PM +0200, Guido Witmond wrote:
My scheme does the opposite. It allows *total strangers* to exchange
keys securely over the internet.
With a FOAF routing scheme with just 3 degrees of separation
there are not that many strangers left.
If you add opportunistic
2013/9/11 William Allen Simpson william.allen.simp...@gmail.com
It bugs me that so many of the input words are mostly zero. Using the
TLS Sequence Number for the nonce is certainly going to be mostly zero
bits. And the block counter is almost all zero bits, as you note,
(In the case of
On 09/11/13 10:43, Eugen Leitl wrote:
On Tue, Sep 10, 2013 at 09:01:49PM +0200, Guido Witmond wrote:
My scheme does the opposite. It allows *total strangers* to
exchange keys securely over the internet.
With a FOAF routing scheme with just 3 degrees of separation there
are not that many
On Sep 10, 2013, at 6:43 PM, Nemo n...@self-evident.org wrote:
GET / HTTP/1.1\r\n is exactly 16 bytes, or one AES block. If the IV is
sent in the clear -- which it is -- that is one plaintext-ciphertext
pair right there for every HTTPS connection.
In fact, _any_ aligned 16 bytes of
On Tue, Sep 10, 2013 at 2:04 PM, Joe Abley jab...@hopcount.ca wrote:
As an aside, I see CAs with Chinese organisation names in my browser list.
I wouldn't pick on/fear/call out the Chinese specifically.
Also, be aware that browsers must transitively trust all the issuers
that the known trust
On 9/11/13 6:00 AM, Alexandre Anzala-Yamajako wrote:
Chacha20 being a stream cipher, the only requirement we have on the ICV is
that it doesn't repeat isn't ?
You mean IV, the Initialization Vector. ICV is the Integrity Check Value,
usually 32-64 bits appended to the packet. Each is
On 9/11/13 10:27 AM, Adam Langley wrote:
[attempt two, because I bounced off the mailing list the first time.]
On Tue, Sep 10, 2013 at 9:35 PM, William Allen Simpson
william.allen.simp...@gmail.com wrote:
Why generate the ICV key this way, instead of using a longer key blob
from TLS and
A quick note: many recent postings with very useful content have gone
out with entirely inappropriate Subject: lines because of threads
shifting topics. Always look at your Subject: line and ask yourself
if it should be updated.
(And thank all of you for not top posting. It is appreciated.)
On Sep 11, 2013, at 9:16 AM, Andrew W. Donoho a...@ddg.com wrote:
Yesterday, Apple made the bold, unaudited claim that it will never save the
fingerprint data outside of the A7 chip.
By announcing it publicly, they put themselves on the line for lawsuits and
regulatory actions all over the
I agree that randomness-reuse is a major issue. Recently about 55 Bitcoin were
stolen by exploiting this, for example:
http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/
However, it is quite straightforward to make yourself safe from re-used nonces
in (EC)DSA, like
Yesterday, Apple made the bold, unaudited claim that it will never save the
fingerprint data outside of the A7 chip.
Why should we trust Cook Co.?
I'm not sure it matters. If I want your fingerprint, I'll lift it off your
phone.
--
Principal Security Engineer
Akamai Technology
From the title it sounds like you're talking about my 2007 proposal:
http://www.lshift.net/blog/2007/11/10/squaring-zookos-triangle
http://www.lshift.net/blog/2007/11/21/squaring-zookos-triangle-part-two
This uses key stretching to increase the work of generating a colliding
identifier from 2^64
http://www.mathbulletin.com/research/Breakthrough_in_cryptography_could_result_in_more_secure_computing.asp
Breakthrough in cryptography could result in more secure computing
(9/10/2013)
Tags: computer science, research, security, cryptography
Nigel Smart, Professor of Cryptology
New
The recent flood of discussions has touched on many modern attacks on
cryptosystems. I'm long out of the crypto world [I last had a crypto
clearance *before* differential cryptanalysys was public info!]. Attacks
that leak a bit at a time strike me as amazing. I remember reading about
On Tue, Sep 10, 2013 at 12:56:16PM -0700, Bill Stewart wrote:
I thought the normal operating mode for PFS is that there's an
initial session key exchange (typically RSA) and authentication,
which is used to set up an encrypted session, and within that
session there's a DH or ECDH key exchange
On 11 Sep 2013 18:37, Bernie Cosell ber...@fantasyfarm.com wrote:
The recent flood of discussions has touched on many modern attacks on
cryptosystems. I'm long out of the crypto world [I last had a crypto
clearance *before* differential cryptanalysys was public info!]. Attacks
that leak a
http://csrc.nist.gov/publications/PubsDrafts.html
Sep. 9, 2013
SP 800-90 A Rev 1 B and C
DRAFT Draft SP 800-90 Series: Random Bit Generators
800-90 A Rev. 1: Recommendation for Random Number Generation Using
Deterministic Random Bit Generators
800-90 B: Recommendation for the Entropy
On 09/11/2013 12:54 PM, Alan Braggins wrote:
On 10/09/13 15:58, james hughes wrote:
On Sep 9, 2013, at 9:10 PM, Tony Arcieri basc...@gmail.com
mailto:basc...@gmail.com wrote:
On Mon, Sep 9, 2013 at 9:29 AM, Ben Laurie b...@links.org
mailto:b...@links.org wrote:
And the brief summary is:
At 10:39 AM 9/11/2013, Phillip Hallam-Baker wrote:
Perfect Forward Secrecy is not perfect. In fact it is no better than
regular public key. The only difference is that if the public key
system is cracked then with PFS the attacker has to break every
single key exchange and not just the keys in
On Wed, 11 Sep 2013, Bernie Cosell wrote:
Anyhow, are there any (not *too* technical) books on the modern
techniques for attacking cryptosystems?
Really depends what you mean by attacking; there are attacks at the
protocol level (e.g., padding-oracle attacks), at the crypto level (e.g.,
On Sep 11, 2013, at 1:44 PM, Tim Dierks t...@dierks.org wrote:
When it comes to litigation or actual examination, it's been demonstrated
again and again that people can hide behind their own definitions of terms
that you thought were self-evident. For example, the NSA's definition of
On Sep 11, 2013, at 6:16 AM, Andrew W. Donoho a...@ddg.com wrote:
Yesterday, Apple made the bold, unaudited claim that it will never save
the fingerprint data outside of the A7 chip.
If you watch the video at http://www.apple.com/apple-events/september-2013/,
Dan Riccio says at 61:08
On 2013-09-10 4:30 PM, ianG wrote:
The question of whether one could simulate a raw physical source is
tantalising. I see diverse opinions as to whether it is plausible,
and thinking about it, I'm on the fence.
Let us consider that source of colored noise with which we are most
familiar:
On Wed, Sep 11, 2013 at 2:40 PM, Bill Stewart bill.stew...@pobox.comwrote:
At 10:39 AM 9/11/2013, Phillip Hallam-Baker wrote:
Perfect Forward Secrecy is not perfect. In fact it is no better than
regular public key. The only difference is that if the public key system is
cracked then with PFS
as amazing. I remember reading about
attacks that involved running chips at lower voltage than they were
supposed to have and that somehow allowed them to be compromised, etc.
Voltage Glitching?
A neighborly paper:
Hello,
Over the past year I was in contact with different cryptographers (I was
designing a new symmetric algorithm) and they all told me in order to publish
it no governmental authorization was needed. They also told me that they
publish paper all the time without having an authorization.
On 9/11/13 10:37 AM, Adam Langley wrote:
On Tue, Sep 10, 2013 at 10:59 PM, William Allen Simpson
william.allen.simp...@gmail.com wrote:
Or you could use 16 bytes, and cover all the input fields There's no
reason the counter part has to start at 1.
It is the case that most of the bottom
I have attempted to produce a summary of the discussion so far for use as a
requirements document for the PRISM-PROOF email scheme. This is now
available as an Internet draft.
http://www.ietf.org/id/draft-hallambaker-prismproof-req-00.txt
I have left out acknowledgements and references at the
On 08/09/2013 21:51, Perry E. Metzger wrote:
I wrote about this a couple of weeks ago, see:
http://www.metzdowd.com/pipermail/cryptography/2013-August/016872.html
In short, https to a server that you /do/ trust.
Problem is, joe average is not going to set up his own server. Making
setting
On Wed, Sep 11, 2013 at 1:13 PM, Jerry Leichter leich...@lrw.com wrote:
On Sep 11, 2013, at 9:16 AM, Andrew W. Donoho a...@ddg.com wrote:
Yesterday, Apple made the bold, unaudited claim that it will never save
the fingerprint data outside of the A7 chip.
By announcing it publicly, they put
On Wed, 11 Sep 2013 06:49:45 +0200 Raphael Jacquot
sxp...@sxpert.org wrote:
according to http://en.wikipedia.org/wiki/Padding_(cryptography) ,
most protocols only talk about padding at the end of the cleartext
before encryption. now, how about adding some random at the
beginning of the
On 11/09/13 12:23, Paul Crowley wrote:
From the title it sounds like you're talking about my 2007 proposal:
http://www.lshift.net/blog/2007/11/10/squaring-zookos-triangle
http://www.lshift.net/blog/2007/11/21/squaring-zookos-triangle-part-two
This uses key stretching to increase the work of
On Sep 11, 2013, at 5:57 PM, Nemo n...@self-evident.org wrote:
The older literature requires that the IV be unpredictable (an
ill-defined term), but in fact if you want any kind of security proofs
for CBC, it must actually be random.
Wrong, according to the Rogaway paper you cited. Pull up
On 09/11/13 13:23, Paul Crowley wrote:
From the title it sounds like you're talking about my 2007 proposal:
http://www.lshift.net/blog/2007/11/10/squaring-zookos-triangle
http://www.lshift.net/blog/2007/11/21/squaring-zookos-triangle-part-two
This uses key stretching to increase the work
Jerry Leichter leich...@lrw.com writes:
The older literature requires that the IV be unpredictable (an
ill-defined term), but in fact if you want any kind of security proofs
for CBC, it must actually be random.
Wrong, according to the Rogaway paper you cited. Pull up
It occurs to me that specifying IVs for CBC mode in protocols
like IPsec, TLS, etc. be generated by using a block cipher in counter
mode and that the IVs be implicit rather than transmitted kills two
birds with one stone.
The first bird is the obvious one: we now know IVs are unpredictable
and
Another whacky idea...
Given that there is One True Source of randomness to wit radioactive
emission, has anyone considered playing with old smoke detectors?
The ionising types are being phased out in favour of optical (at least in
Australia) so there must be heaps of them lying around.
I
Phillip Hallam-Baker hal...@gmail.com writes:
I have attempted to produce a summary of the discussion so far for use
as a requirements document for the PRISM-PROOF email scheme. This is
now available as an Internet draft.
http://www.ietf.org/id/draft-hallambaker-prismproof-req-00.txt
First,
On Thu, 12 Sep 2013 08:47:16 +1000 (EST) Dave Horsfall
d...@horsfall.org wrote:
Another whacky idea...
Given that there is One True Source of randomness to wit
radioactive emission, has anyone considered playing with old smoke
detectors?
People have experimented with all sorts of stuff, and
Jerry Leichter leich...@lrw.com writes:
The real problem is that unpredictable has no definition.
Rogaway provides the definition in the paragraph we are discussing...
Rogoway specifically says that if what you mean by unpredictable is
random but biased (very informally), then you lose some
On Sep 11, 2013, at 6:51 PM, Perry E. Metzger wrote:
It occurs to me that specifying IVs for CBC mode in protocols
like IPsec, TLS, etc. be generated by using a block cipher in counter
mode and that the IVs be implicit rather than transmitted kills two
birds with one stone.
Of course, now
On Wed, 11 Sep 2013 20:01:28 -0400 Jerry Leichter leich...@lrw.com
wrote:
...Note that if you still transmit the IVs, a misimplemented
client could still interoperate with a malicious counterparty
that did not use the enforced method for IV calculation. If you
don't transmit the IVs at all
45 matches
Mail list logo
