Re: [cryptography] Can there be a cryptographic "dead man switch"?

[mhey...@gmail.com]

On Wed, Sep 19, 2012 at 5:33 PM, Tim Dierks  wrote:
>
> If the "trustee" doesn't have access to the "safe" until after you're
> dead, then the encryption is unimportant: just keep your secrets
> in the safe unencrypted. If they can access the encrypted
> message before your dead, they can decrypt it in a few months
>
On Wed, Sep 19, 2012 at 5:08 PM, The Fungi  wrote:
>
> And how does the trustee get access to the encrypted form of the
> secret? If he has a copy of it encrypted with the old key, how do
> you ensure he throws it out when you reencrypt with the new key? If
> he doesn't get access to the encrypted secret until you die, then
> why not simply rely on that access mechanism and forget about
> encrypting it in the first place?
>
These are all good questions and correct because I didn't explain the
scheme well enough.

The trustee gets access to the encrypted secret as part of the estate.
If anybody, including the trustee, gets access to the encrypted secret
before death, the secret must be made worthless.

I was assuming the decrypted secret was similar to "locations of his
caches of gold" example from the original posting. When the grantor
detects that somebody may have gained access to the encrypted secret,
they have time to move the caches of gold. After moving the caches,
revealing the old secret no longer has any value.

Note, the encryption is still important because provides time to the
grantor to move the "caches of gold", thus keeping the valuables from
discovery. To enforce a reasonable amount of time to move the "caches
of gold", the encrypted secret sitting in the grantor's "safe" should
actually be onion-wrapped in weak keys. Just getting access to the
encrypted secret with the now revealed key delivered to the trustee
isn't enough. The onion-wrapping of the secret means one must still
break a number of day-strong keys before gaining access to the
"locations of caches of gold".

Yes, this scheme is pretty far from a crypto-only solution because it
requires the ability to move the "caches of gold" around in the
physical world - with the possibility of surveillance completely
bypassing the crypto altogether. As, such, it is not very clean and
elegant but it does satisfy the motivating application.

Michael Heyman
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Can there be a cryptographic "dead man switch"?

[mhey...@gmail.com]

Doh, don't know why I brought public-key crypto into this. There isn't
a need for it. Just pick, say, an AES key and give the trustee some of
the key's bits so they only have to brute force part of the key.

On Wed, Sep 19, 2012 at 4:48 PM, mhey...@gmail.com  wrote:
> On Wed, Sep 5, 2012 at 9:51 AM, StealthMonger
>  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>>
>> Can there be a cryptographic "dead man switch"?  A secret is to be
>> revealed only if/when signed messages stop appearing.  It is to be
>> cryptographically strong and not rely on a trusted other party.
>>
> Every three months I, the Grantor, encrypt my secret in a new
> secret-encrypting-key and place that secret in my box. (I keep my box
> away from others - maybe put it in a safe).
>
> I also encrypt that secret-encrypting key in a public key but not too
> strong a public key, one that can be broken in three months time.
>
> I then throw away the private key to that public key (I don't need it,
> I know my secret).
>
> I give the public-key encrypted secret-encrypting key to the trustee,
> heck I can publish it on the web if I want.
>
> If I should die, I will stop re-encrypting the secret and the trustee
> (that I never really trusted) can break the public key and get to the
> secret.
>
> I know a second scheme that we worked out years ago when one of our
> group was working on DTN (delay tolerant networking) where we would
> encrypt something and bounce the encrypting key off a distant node and
> get a few seconds or minutes of safe time until the something could
> get decrypted. This scheme has the benefit of not failing if some
> whiz-bang new crypto breaking system comes along but deals with much
> shorter time periods. I assume that if I'm using the crypto-only
> method, then I will keep apprised of whiz-bang new crypto breaking
> systems and re-encrypt early with a larger key to get back on my three
> month schedule if such a faster breaking system should appear.
> 
> Michael Heyman
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Can there be a cryptographic "dead man switch"?

[mhey...@gmail.com]

On Wed, Sep 5, 2012 at 9:51 AM, StealthMonger
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
>
> Can there be a cryptographic "dead man switch"?  A secret is to be
> revealed only if/when signed messages stop appearing.  It is to be
> cryptographically strong and not rely on a trusted other party.
>
Every three months I, the Grantor, encrypt my secret in a new
secret-encrypting-key and place that secret in my box. (I keep my box
away from others - maybe put it in a safe).

I also encrypt that secret-encrypting key in a public key but not too
strong a public key, one that can be broken in three months time.

I then throw away the private key to that public key (I don't need it,
I know my secret).

I give the public-key encrypted secret-encrypting key to the trustee,
heck I can publish it on the web if I want.

If I should die, I will stop re-encrypting the secret and the trustee
(that I never really trusted) can break the public key and get to the
secret.

I know a second scheme that we worked out years ago when one of our
group was working on DTN (delay tolerant networking) where we would
encrypt something and bounce the encrypting key off a distant node and
get a few seconds or minutes of safe time until the something could
get decrypted. This scheme has the benefit of not failing if some
whiz-bang new crypto breaking system comes along but deals with much
shorter time periods. I assume that if I'm using the crypto-only
method, then I will keep apprised of whiz-bang new crypto breaking
systems and re-encrypt early with a larger key to get back on my three
month schedule if such a faster breaking system should appear.

Michael Heyman
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] Key escrow 2012

[mhey...@gmail.com]

On Thu, Mar 29, 2012 at 6:38 PM, Jon Callas  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> On Mar 29, 2012, at 2:48 PM, mhey...@gmail.com wrote:
>
>> On Tue, Mar 27, 2012 at 1:17 PM, Nico Williams  wrote:
>>> On Tue, Mar 27, 2012 at 5:18 AM, Darren J Moffat
>>>>
>>>> For example an escrow system for ensuring you can decrypt data written by
>>>> one of your employees on your companies devices when the employee forgets 
>>>> or
>>>> looses their key material.
>>>
>>> Well, the context was specifically the U.S. government wanting key
>>> escrow.
>>>
>> Hmm - these are not mutually exclusive.
>>
>> Back in the mid to late 90s, the last time the U.S. government
>> required key escrow for international commerce with larger key sizes,
>> they allowed key escrow systems that were controlled completely by the
>> company. Specifically, they allowed Trusted Information System's
>> RecoverKey product (I worked on this one, still have the shirt, and am
>> not aware of any other similar products available at the time - PGP's
>> came later and was more onerous to use).
>>
>> RecoverKey simply wrapped a session key in a corporate public key
>> appended to the same session key wrapped with the user's public key.
>> If the U.S. Government wanted access to the data, the only thing they
>> got was the session key after supplying the key blob and a warrant to
>> the corporation in question. The U.S. government even allowed us to
>> sell RecoverKey internationally to corporations that kept their
>> RecoverKey data recovery centers offshore but agreed to keep them in a
>> friendly country.
>
> I'd have to disagree with you on much of that.
>
> The US Government never required key escrow for international commerce.
> Encrypted data was never restricted, what was restricted was the export of
> software etc
>
So, your second sentence disagrees with your first? In the real but
rapidly changing world that existed back then, if you wanted to export
cryptographic software that used strong keys from the U.S., you needed
key escrow. Or, of course, you could publish a book of your source
code ;-) (although that wasn't proven legal until 1999).
>
> Amusingly, I ended up having TIS's RecoverKey under my bailiwick because
> Network Associates bought PGPi and then TIS. The revenues from it were
> so small that I don't think they even covered marketing material like that 
> shirt
> you had. In a very real sense, it didn't exist as anything more than a 
> proof-of-
> concept that proved the concept was silly.
>
What do you mean 'had', I still have the shirt!

No argument on the silliness but if the government hadn't relaxed the
rules and you had a pile of non-U.S. installations of Microsoft
applications (Outlook, IE, and other code using the Microsoft
CryptoAPI) and you wanted strong crypto, then RecoverKey was the
_only_ option. Now, back then, most internationals were happy with the
Microsoft's base cryptographic service provider (512-bit RSA key
exchange, 40-bit RC2, 40-bit RC4, DES(-40?)). Deep Crack was changing
that but then, probably because of Deep Crack, impending rule changes
made RecoverKey almost irrelevant.
>
> Also, there wasn't a PGP system. The PGP "additional decryption key" is
> really what we'd call a "data leak prevention" hook today, but that term
> didn't exist then.
>
I was just using the PGP additional decryption key design as an
example of something that used a similar technique of encrypting the
session key under more than one public key.

As for data leak prevention, that isn't what we other Network
Associates employees heard back then. We were told and used the PGP
ADK thing as if it would help us when we lost our private keys (along
with protecting the company from employees that try to hold data
hostage). I remember trying to get company officers to get their key
shares together to please please please recover my backup encrypted
volume. Alas, I had no success and had to do a few weeks of scrambling
to recover the old fashioned way. I admit I was  young, naive, and
tainted by having worked on RecoverKey where the data recovery center
sat in a room with a modem happily waiting for me to recover my own
keys.

Yes, RecoverKey was never much more than a commercial grade
proof-of-concept. But, it was well thought out, satisfied a real,
albeit an artificially-created-by-stupid-policy need, and it did work
as advertised.

-Michael Heyman
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Key escrow 2012

[mhey...@gmail.com]

On Tue, Mar 27, 2012 at 1:17 PM, Nico Williams  wrote:
> On Tue, Mar 27, 2012 at 5:18 AM, Darren J Moffat
>>
>> For example an escrow system for ensuring you can decrypt data written by
>> one of your employees on your companies devices when the employee forgets or
>> looses their key material.
>
> Well, the context was specifically the U.S. government wanting key
> escrow.
>
Hmm - these are not mutually exclusive.

Back in the mid to late 90s, the last time the U.S. government
required key escrow for international commerce with larger key sizes,
they allowed key escrow systems that were controlled completely by the
company. Specifically, they allowed Trusted Information System's
RecoverKey product (I worked on this one, still have the shirt, and am
not aware of any other similar products available at the time - PGP's
came later and was more onerous to use).

RecoverKey simply wrapped a session key in a corporate public key
appended to the same session key wrapped with the user's public key.
If the U.S. Government wanted access to the data, the only thing they
got was the session key after supplying the key blob and a warrant to
the corporation in question. The U.S. government even allowed us to
sell RecoverKey internationally to corporations that kept their
RecoverKey data recovery centers offshore but agreed to keep them in a
friendly country.

-Michael Heyman
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Password non-similarity?

[mhey...@gmail.com]

On Sat, Dec 31, 2011 at 5:02 PM, Landon  wrote:
>
> A lot of the password reuse is simply adding +1 or something on
> the end. Since the base of the password stays the same, couldn't
> you just hash the first and second halves of the new and old
> passwords separately and compare each pair? (Or any arbitrary
> length) Then if they match you can reject the password.
>
Sounds reasonable, but

This utterly breaks security from offline attacks unless you double
the length of the required password. Now, instead of brute-forcing  8
or 10ish character passwords, an attacker that obtained the hashes
must only brute force two 4 or 5ish character sub-passwords - a much
easier proposition.

-Michael Heyman
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] How are expired code-signing certs revoked?

[mhey...@gmail.com]

On Wed, Dec 7, 2011 at 4:32 PM, Peter Gutmann  wrote:
>
>  In the presence of such a [self-revoking] revocation [of a root certificate]
> applications can react in one of three ways: they can accept the CRL
> that revokes the certificate as valid and revoke it, they can reject the
> CRL as invalid because it was signed by a revoked certificate, or
>  they can crash...
>
Um, the real problem is not revoking the root certificate but what
other certificates to temporarily trust in the face of the revoked
root certificate (In the past, I have chosen the simplest to code
option of "none" but with the knowledge that things might break).

In a CRL that contains an element that revokes the CRL signing
certificate, only that element can be assumed to be correct. All other
list elements are suspect.

If a self-signed CA certificate lands in that CA's CRL, then, of
course the self-signed certificate can now be considered compromised.
Either the original private key signed the CRL or the compromising
copy signed it - both cases mean the root private key must be
considered compromised. Of course, the second case means some
malicious entity wanted to crash some piece of code that crashes in
this case. I can't think of another reason the malicious entity would
"out" themselves other than crashing buggy code.

All other elements in that CRL, and, indeed, all CRLs dating back to
the time of the compromise, might be invalid CRL elements. Code I have
written in the past assumed those certificates were invalid even
though they might not be. This was with full knowledge of the possible
but unlikely denial-of-service attack (there are so many better things
one can do with a compromised CA key then issue bad CRLs). Any
CRL-based DoS attack doesn't need to last too long because the CA can
issue new certificates signed with a new key in short order - getting
the new certificates including the new root certificate distributed,
of course, can take more time.

-Michael Heyman
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] RFC: randomness from timer demon

[mhey...@gmail.com]

On Sun, Oct 9, 2011 at 1:56 AM, Sandy Harris  wrote:
> On Tue, Sep 27, 2011 at 2:04 PM, Sandy Harris  wrote:
>
>> ...[code and pdf] is at: ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/
>>
>> That should be available for anon FTP, but I have not tested it from
>> outside the university.
>
> I & others have now. Works fine...
>
I cannot get anything from the 990 port and cannot get through the
login at the default FTP port.

-Michael Heyman
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Tossing randomness back in?

[mhey...@gmail.com]

On Tue, Apr 19, 2011 at 12:55 AM, Marsh Ray  wrote:
>
> You do not need to decrement the entropy estimate of the pool
> as you generate random numbers from it...IIRC, Peter Gutmann
> was using the term "computational entropy" to refer to the
> entropy seemingly generated within the hash function. But I don't
> think he was willing to go all the way to conclude that the pool
> entropy was nondecreasing.
>
As well he shouldn't. The entropy of the pool does decrease because
the number of possible states it can be in reduces upon every update
(up to a point). The 'conditional computational entropy' (that entropy
experienced by real hardware with bounded performance and memory)
doesn't decrease because there is no way for real hardware to
enumerate all possible states of the pool and remove those it can no
longer be in after an iteration.

-Michael Heyman
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] AES side channel attack using a weakness in the Linux scheduler

[mhey...@gmail.com]

On Wed, Nov 24, 2010 at 3:20 PM, coderman  wrote:
> On Wed, Nov 24, 2010 at 8:26 AM, Jack Lloyd  wrote:
>>
>> An interesting new eprint on attacking AES using cache timings
>> "Cache Games - Bringing Access Based Cache Attacks on AES to Practice"
>> Endre Bangerter and David Gullasch and Stephan Krenn
>> http://eprint.iacr.org/2010/594
>>
>> What are people's thoughts on these kinds of local cache attacks, in
>> terms of actual systems security?
>
> good reasons to use a hardware AES implementation like AES-NI or XCRYPT.
>
Or OpenSSL 1.0 which is immune (the paper references 0.9.8n and says
1.0 is immune).

-Michael Heyman
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] looking for 'small' AES source

[mhey...@gmail.com]

On Sat, Oct 23, 2010 at 8:18 AM, mhey...@gmail.com  wrote:
> On Sat, Oct 23, 2010 at 5:54 AM, Ilya Levin  wrote:
>> On Wed, Oct 20, 2010 at 11:34 PM, mhey...@gmail.com  
>> wrote:
>>>
>>> Does anybody have a pointer to unencumbered C code written to be space
>>> efficient? (All the AES code I have trades space for speed).
>>
>> There is a byte-oriented AES-256 implementation in C available at
>> http://bit.ly/cnEU26
>>
This also pointed me to
<http://gladman.plushost.co.uk/oldsite/AES/aes-byte-29-08-08.zip>
which does 128 so it is what I'm going with.

Michael Heyman
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] looking for 'small' AES source

[mhey...@gmail.com]

Oops, the implementation you noted does not do key expansion. It wins!

On Sat, Oct 23, 2010 at 8:18 AM, mhey...@gmail.com  wrote:
> On Sat, Oct 23, 2010 at 5:54 AM, Ilya Levin  wrote:
>> On Wed, Oct 20, 2010 at 11:34 PM, mhey...@gmail.com  
>> wrote:
>>>
>>> Does anybody have a pointer to unencumbered C code written to be space
>>> efficient? (All the AES code I have trades space for speed).
>>
>> There is a byte-oriented AES-256 implementation in C available at
>> http://bit.ly/cnEU26
>>
>> It might be something that you are looking for.
>>
> That's great. I also just found
> <http://sourceforge.net/projects/adv-aes-encrypt> which has a small
> AES with lots of globals and a hard-coded key. It does do the
> different sizes of AES, but only does it at compile time. So, I need
> AES128 and I have to pick between these as starting points. Both of
> these do key expansion which takes memory and isn't needed for
> performance reasons if only encrypting things less than the expanded
> key size - 176, 208, and 240 bytes for AES128,192,256 respectively
> (which I think my project does).
> 
> Michael Heyman
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] looking for 'small' AES source

[mhey...@gmail.com]

On Sat, Oct 23, 2010 at 5:54 AM, Ilya Levin  wrote:
> On Wed, Oct 20, 2010 at 11:34 PM, mhey...@gmail.com  wrote:
>>
>> Does anybody have a pointer to unencumbered C code written to be space
>> efficient? (All the AES code I have trades space for speed).
>
> There is a byte-oriented AES-256 implementation in C available at
> http://bit.ly/cnEU26
>
> It might be something that you are looking for.
>
That's great. I also just found
<http://sourceforge.net/projects/adv-aes-encrypt> which has a small
AES with lots of globals and a hard-coded key. It does do the
different sizes of AES, but only does it at compile time. So, I need
AES128 and I have to pick between these as starting points. Both of
these do key expansion which takes memory and isn't needed for
performance reasons if only encrypting things less than the expanded
key size - 176, 208, and 240 bytes for AES128,192,256 respectively
(which I think my project does).

Michael Heyman
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] looking for 'small' AES source

[mhey...@gmail.com]

I have to squeeze AES onto a small chip with not much RAM. The
Rijndael Specification from the AES submission discusses code that
doesn't fully expand the key and performs the round transformation in
less space.

Does anybody have a pointer to unencumbered C code written to be space
efficient? (All the AES code I have trades space for speed).

Thanks,

-Michael Heyman
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] "stream MAC" - does anything like it exist?

[mhey...@gmail.com]

On Fri, Sep 10, 2010 at 2:06 PM,
 wrote:
> ...something where you can spend a few bits authenticating each
>  frame of a movie, or sound sample, for example, and have some
>  probabilistic chance of detecting alteration at each frame.
>
On Sun, Sep 12, 2010 at 9:15 PM, Chris Palmer  wrote:
> James A. Donald writes:
> I agree with Bellovin that truncating the MAC is of little benefit except in
> bandwidth-constrained applications --- truncating the MAC decreases its
> protective power. There may be situations in which it's a fine trade-off, of
> course.
>
I don't think full authentication tags on video or sound amount to
enough bits to care about reducing them.

Also having done some work in the past with respect to reduced
authentication (albeit per packet, not per frame),
,
I can tell you that while I agree that reducing authentication per
packet on video or sound doesn't hurt overall authenticity when
occasionally bad packets get through, it is very difficult to come up
with an application that can actually show benefit stemming from
reducing authentication. The 50,000 ft view is that IPsec HMAC-SHA1
costs about the same amount of processing as TCP. Almost anything else
you do with video or sound will cost orders of magnitude more. A
coworker was actually able to cobble a demo together that showed an
effect from faster authentication by sending uncompressed video over
the network to max it out. The host then did a straight copy of the
unconverted video to the graphics card. Even with the heaviest
authentication (HMAC-SHA1) the video was completely intelligible with
only the occasional stutter.

-Michael Heyman
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] is there an interation-incremental version of PBKDF2?

[mhey...@gmail.com]

On Thu, Sep 9, 2010 at 2:28 PM, Marsh Ray  wrote:
> On 09/08/2010 05:06 PM, travis+ml-rbcryptogra...@subspacefield.org wrote:
>>
 On Fri, Sep 03, 2010 at 09:45:20AM +0100, Ben Laurie wrote:

 ...narrow-pipe designs have a huge null space for messages which
 are exactly as big as the compression function input size. For
 instance hashing inputs that are multiples of 512 bits, SHA-256
 will only produce about 63% of the possible 2^256 outputs.

>>> So we deal with SHA-255.33 instead of SHA-256. Not a big enough
>>> difference to worry about.
>
> But without a fresh injection of entropy, the effective entropy in the
> resulting hash is reduced more than half a bit per log2
> of the iteration count.
>
First of all, half a bit per log2 isn't quite true.

See "Random Mapping Statistics", Flajolet, A Odlyzko, Advances in
cryptology, EUROCRYPT'89, 1990
.

The paper shows the bits of entropy lost is:
   log2(1-t(k))
where:
   t(k+1) = e^(t(k)-1)

So, for instance, by the 256rd iteration, you have only lost 7.01 bits
of entropy, not 8 bits. And, you will never get below
  ( ( pi*(2^n) )/2 )^0.5
where 'n' is the number of bits in the hash you iterate over. This is
about 128.3 bits for SHA-256.

Restated with no equations: An iterated hash will make a graph with
multiple trees attached to multiple cycles. If you start on a tree,
each iteration walks down the tree and eventually lands on a cycle. It
looks like a pile of hairy loops or a flock of flying spaghetti
monsters. At every iteration, the entropy goes down simply because of
a reduced possibility of states. This happens because the state cannot
possibly be at a branch terminal after one iteration. The state cannot
possibly be at a branch terminal or next to it after two iterations.
Once you have iterated enough that you cannot possibly be on a tree
but must be in a cycle, the entropy will never go down again.

Second of all, the vast majority of discussions about losing entropy
this way is completely mute.

These entropy discussions are mute because in the real world we don't
care about 'entropy' we care about what I have heard referred to as
'conditional computational entropy' or the entropy experienced by
somebody with a real device, not a device that can enumerate all
states in an iterated 256-bit hash and know which states can be
excluded.

Back in the real world, we don't lose any 'conditional computational
entropy' upon iteration.

We don't lose any 'conditional computational entropy' upon iteration
because we have no machines powerful enough to know what states are at
branch-terminals or next to branch-terminals or next to those, etc.

-Michael Heyman
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography