Cryptography-Digest Digest #198, Volume #11 Fri, 25 Feb 00 08:13:01 EST
Contents:
Status of alleged *THIRD* key in MS Crypto API ? (Francois Grieu)
NSA now has a FAQ ("Douglas A. Gwyn")
Digital Tontines [Was: FIRST TIME!] ("Matthew S. Hamrick")
Re: I had me an Idea (Dynamic Key Encription) ("Matt Hall")
Re: Implementation of Crypto on DSP (David A Molnar)
Re: Passwords secure against dictionary attacks? (Jens Haug)
Cryption Techniques and others ("Osah")
Re: I had me an Idea (Dynamic Key Encription) (John Savard)
Re: QUESTION: Enigma Machine Plans, specification etc (John Savard)
Re: FIRST TIME! (John Savard)
Re: Implementation of Crypto on DSP (Christof Paar)
Re: Passwords secure against dictionary attacks? (Runu Knips)
Re: Crypto Speeds... (Runu Knips)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Status of alleged *THIRD* key in MS Crypto API ?
Date: Fri, 25 Feb 2000 10:22:14 +0100
A few weeks ago I read some news on a researcher announcing the
discovery of a *THIRD* key in the Windows code responsible for
checking additional crypto suites, in addition of Microsoft's
primary key and the 'backup' key [known as NSAKEY following the
release of Windows NT service pack 5 with debug symbols not removed].
The researcher supposedly located the third key using a
compressibility heuristic.
What's going on with this story ?
Francois Grieu
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: NSA now has a FAQ
Date: Fri, 25 Feb 2000 09:27:10 GMT
http://www.nsa.gov:8080/about_nsa/faqs_internet.html
------------------------------
From: "Matthew S. Hamrick" <[EMAIL PROTECTED]>
Subject: Digital Tontines [Was: FIRST TIME!]
Date: Fri, 25 Feb 2000 09:37:24 GMT
Jean Pierre wrote:
>
> This is my first time here.
>
> Could someone give me the simplest way to create a simple code to encrypt a
> simple message for a communication to be delivered after my death.
> I thought about something like one those card perforated with holes in
> certain places on a square card andthat one can fill in with a short
> message, and turn the card around to continue.
> At the end, fill the empties with any characters.
>
> I saw this done when I was a kid, but I am not quite sure how to go about
> it.
> Any suggestions? :-)
>
I also am not entirely certian how the method you propose ties in with
your death. However, you can find many, many good encryption algorithms
in various publications such as Scheier's Applied Crypto, Menenzes, et
al. Handbook of Applied Crypto, or Stinson's Crypto:Theory & Practice.
With regards to the 'death' part, you may want to check out
http://www.deathswitch.com/ . They appear to be offering a service that
emails various people upon your 'death', with your 'death' being defined
as when you stop going to thier web site to reset a counter. Not
completely like the watchdog timer on a number of embedded computer
systems.
I don't think they're operational at this point, but my guess is that
they will be soon. One thing you may want to consider doing is selecting
a random key, write some messages to be sent to people upon your
'death', encrypt the messages with the random key, deliver the encrypted
messages to the people on your list. Then, setup something with
deathswitch.com so that the random key is delivered after your 'death.'
They use the key to decrypt the message, and viola! messages from beyond
the 'grave.'
The obvious problem with this technique is that a) deathswitch requires
that you login to thier service one every-so-often to reset the 'death
counter,' and let's say that you're in a coma for couple of years and
can't login. Well, deathswitch isn't precisely perfect in this case. b)
You have to trust the guys at deathswitch not to blab your key. c)
assuming that you want to live another 50 years or so, you have to
select email addresses for recipients that won't change over that period
as well as an encryption algorithm and key length that won't be easily
defeatable for that 50 year period. d) there's no authentication to
prove that the 'message from beyond the grave' really came from you, so
some mischevious adversary could fake your 'death.'
So... Addressing points b, c, & d, you may want to add a few things to
the message:
1) Encrypt the key you give to deathswitch with another key that you
give only to the message recipients. In theory, assuming that
deathswitch does not operate a worldwide network of spies and informers,
you should be able to keep the message encryption key secret from
deathswitch.com. Of course, this doesn't protect from collusion between
your message recipients and the operators of deathswitch.com.
2) Add some authenticating information to the encrypted message and the
encrypted key. I think that you could generate a public/private key
pair, sign the message to be encrypted, sign the key that's encrypting
the message, and then destroy the private key. In this case, it might be
enough just to know that the same person signed the original message and
the message encrypting key. Leaving the private key around is just an
invitation for someone to steal your laptop/smartcard/whatever to
recover the key.
3) Depending on the people on your message recipient list, you may want
to do something fun like use a key sharing or splitting technique that
requires multiple people on the list to still be alive to reconstruct
the message encryption key.
4) as for key lengths, I think that a 'back of the envelope' calculation
we made at Uptronics indicated that we believed that an 88 bit key would
be sufficient for the next 20 years, I think I heard recently a
recommendation for a 90 bit key (for symmetric algorithms with work
factors similiar to DES.) Assuming that Moore's law holds for years
21-50, maybe a 110 bit key. Awe heck, just use RC5 or whatever the AES
winner turns out to really be with a 256 bit key and crank your PGP
asymmetric key generator up to 4096 bits. Still, keep in mind that
advances in mathematics and computing technologies that will occur in
the next 50 years may not be forseeable from our current vantage point.
No doubt others in this list may have more issues with this solution. It
does, however, introduce an interesting problem. Assume that you want to
setup a digital Tontine. A tontine being a traditional arrangement
between a group of individuals that some common property should be
bequeathed to the last living member of the group.
(http://www.lectlaw.com/def2/t094.htm) I am led to believe from watching
episodes of M*A*S*H that they were wildly popular amongst American
Cavalry officers during the first world war. Using something like
deathswitch, a digital tontine can be easily constructed. I'm using the
term 'digital tontine' to mean a system where some digital information
is delivered to the last 'living' member of a group; the digital
information can be anything, I suppose, the key to decrypt the
instructions for removing $10,000,000 from a numbered swiss bank
account, a digital coin, a tasteless jpeg, it doesn't matter. Also,
'living' can be interpreted in many different ways. Let's suppose you
want some critical information (like the password to the firewall
configuration utility) to be delivered to the last member of your IT
staff that hasn't moved on to work at a small starup in silicon valley.
1) Select the 'Message' to be delivered to the last living member.
2) Generate a public/private key pair. Sign the Message with the private
key.
3) Generate a random 'Message Encryption Key' (MEK), encrypt the message
with the MEK.
4) Publish the encrypted message from step 1 and the public key from
step 2 to the members of the tontine.
5) Split the MEK using some key splitting technique like BBS using N+1
shares where 'N' is the number of members of the tontine. Sign each of
the shares with the private key generated in step 2.
6) Destroy the private key from step 2.
7) Email share # N+1 to each of the members of the tontine.
8) For each member 'i' in the tontine (from 1 to N):
a) Email share # i to member # i
b) Member 'i' sends his signed share to deathswitch.com, specifying
that each member of the tontine should recieve his/her share upon
his/her death.
9) Wait for members of the tontine to start dropping like flies.
Obviously, this assumes that members of the tontine are trustworthy. The
public key from step 2 can be used to ensure that the message and shares
recieved from deathswitch.com are authentic. Using N+1 key shares
(instead of N shares) ensures that the operators of deathswitch.com
can't combine the 'N' shares to reconstruct the MEK, of course some
subset of the tontine members might still bribe deathswitch.com to
reveal all the key shares. Also, you might want to come up with a
program that can submit things to deathswitch.com on each of the tontine
members behalfs if you don't trust them to do it correctly.
Has anyone else done any work on this? A simple search on
'digital-tontine' resulted in no hits on google.com or alta-vista. If
not, this might be a fun (if morbid) subject for an undergraduate,
graduate, or amateur research project. If I may suggest topics for
further research:
1) Message Recovery. Under which circumstances should the message or
message encryption key be recovered (other than the death of N-1 members
of the tontine.
2) Application. There might be some application of this technique to
selective revelation of secrets to the last member of a corporation
employed by that corporation. Ask your boss if this is something they
would support.
3) Adding new members. In the 'last man employeed' situation described
above, you might want to add new members to the tontine as you hire
replacements as single people leave the company. The digital tontine may
only be of serious use in the event that all but one member of a tontine
leave the company without passing on critical information.
4) Securing yourself from deathswitch.com. Of course deathswitch.com has
only your best interests at heart, but let's assume that thier
management is replaced by CIA operatives, communists, aliens, or
attendees of the Financial Crypto conference. How could you protect
yourself (and your tontine) from collusion of some subset of tontine
members with the newly compromised management at deathswitch.com? Key
Encryption Keys?
5) Patent protection. Assuming that this idea is novel, is disclosing on
this newsgroup sufficient to prevent someone from filing for a patent on
this later, or should I try to write this up and get it published in a
'normal' journal?
Also, my name's not attached to any algorithm or technique, and it's
always been a goal of mine, so if you think this technique has any merit
and assuming it's actually novel, I'd appreciate it if you would refer
to this technique as "Hamrick's Boneheaded Deathswitch Digital Tontine."
------------------------------
From: "Matt Hall" <[EMAIL PROTECTED]>
Subject: Re: I had me an Idea (Dynamic Key Encription)
Date: Fri, 25 Feb 2000 10:21:00 -0000
I would imagine this scheme is very weak in comparison with other systems
available. For a start there are a large number of repeated numbers within
your encrypted text, which must surely be a good starting point for
analysis. Just look at the number of times 10004 appears in the cyphertext,
far more than one would expect for a series of random five digit numbers,
which is essentially what one would want the cyphertext to appear to be. A
typical image will have adjacent pixels with the same colour values meaning
adjacent characters will be encrypted with the same key.
On a different note; the cyphertext is far longer than the plaintext, which
is not a sign of an efficient system. Sorry Tim, I think it needs more work!
Matt
--
** Email: [EMAIL PROTECTED] **
** Web: http://www.thepentagon.com/matt.hall **
Tim <[EMAIL PROTECTED]> wrote in message
news:k_ot4.2696$[EMAIL PROTECTED]...
> I had me an idea one day. Using an image to encrypt data. I call it
Dynamic
> Key Encryption, i have shown it to a few people who may or may not know
much
> about encryption. Most seem interested. I am curios what you think about
it.
>
> Well this is what i got.
> 1 image
> a string of text
> and a set equation( for now).
>
> Each character in the text gets its own "small key". The key comes frome
> pixels of the image. The colors of the pixels are combined with the
> character value to produce and integer. after the Caricter recevs its
Small
> Key the algorithm moves on to the next character and pixel.
>
> R = Red Value of the Pixel
> G = Green Value of the Pixel
> B = Blue Value of the Pixel
> C = Character
> E = Encrypted Value
>
> E = (C+ R- G+ B) * R
>
> C= (E / R) - R + G- B
etc, etc.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Implementation of Crypto on DSP
Date: 25 Feb 2000 11:23:43 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> David A Molnar wrote:
>> ... you can do Cool Stuff by manipulating the fact that every
>> ARM instruction is conditional.
> Of course, C compilers for the ARM do that already..
yes, they do. even so, you can often still beat them on short
stretches of code.
> The more complex and bizarre the ISA, the more help one needs
> from programs (i.e. compilers) to do the bookkeeping necessary
> to correctly exploit the architecture. Since assembly-language
> coding takes a lot of effort for relatively little benefit, and
> the resulting program is totally unportable, it is rarely
> justified. Even when it *is* justified, that is almost always
> for just a tiny fraction of the overall application; the rest
> should be coded in a more expressive and maintainable language.
Yes, indeed. It just seems to me that crypto is one of those rare
cases in which a very small amount of code can act as a bottleneck
for the whole system. Improve that code even a little bit, and you
can see performance benefits. Every other part of the code should
of course be written in something portable and maintainable.
Thanks,
-David
------------------------------
From: [EMAIL PROTECTED] (Jens Haug)
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Passwords secure against dictionary attacks?
Date: 25 Feb 2000 08:22:54 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, John Underwood
<[EMAIL PROTECTED]> writes:
> >Our computer centre suggest choosing a phrase an using every first (or second,
> >or last or whatever) character for the password. For example: My grandma takes 5
> >glasses of whine per evening = Mgt5gowpe, who could guess that password?
>
> In that case, the second letter would produce an even more confusing
> one, provided you remembered the deliberate mis-spelling.
Ok, ok, I'm german, so these things keep happening to me. :-/
> I find the
> deliberate mistake in a well-known (to me) phrase or saying can be quite
> useful - provided it is not a mistake I always make. "To see or not to
> see, that is the answer" (or your own, wrong translation of something
> from another language).
But this is already easier to guess, I believe, because it is kind of
a derivate of something very common.
Jens
------------------------------
From: "Osah" <[EMAIL PROTECTED]>
Subject: Cryption Techniques and others
Date: Fri, 25 Feb 2000 12:43:33 +0100
I'm new to this sort of thing so please forgive me for what i'm about to
ask.
I tried to encrypt a file by XORing it with a string of integers (6bytes in
length), i can decrypt it using the same integer string, but i want to know
how to break it without using these integer strings (Any hint, algorithm
description or code in C/C++ would help a lot).
Also, where can i get more information on crypting algorithms or source
code. I would like to learn more about it and how to implement them......
:-)
Thanks....
Cable_TXG
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: I had me an Idea (Dynamic Key Encription)
Date: Fri, 25 Feb 2000 11:23:23 GMT
On Fri, 25 Feb 2000 06:07:12 GMT, "Tim" <[EMAIL PROTECTED]> wrote,
in part:
>E = (C+ R- G+ B) * R
What do you do when R is zero?
Since E is a five-digit number, it contains information about the
picture in addition to the message in encrypted form. While G and B
are sufficient to obscure the message, if they're hard to guess (since
the image may have solid color areas or nearly solid color areas, this
may not be the case) looking at the factorization of numbers in the
message can lead to guesses about R.
One then reconstructs a red image, if we're dealing with a picture and
not random noise, and from that and the probable properties of text
one can guess G and B.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: QUESTION: Enigma Machine Plans, specification etc
Date: Fri, 25 Feb 2000 11:18:33 GMT
On Fri, 25 Feb 2000 06:04:57 GMT, [EMAIL PROTECTED] (Timothy
Charles Holtom) wrote, in part:
>Does anyone know of sites giving the specifications of the Enigma
>Machine. i.e. how the rotors were wired and how the patch panel
>figured in the overall design.
There are several sites about the Enigma on the internet, including a
number which give the information you seek.
My site is one of them.
From
http://home.ecn.ab.ca/~jsavard/roto02.htm
you can directly proceed to any of my pages about the Enigma.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: FIRST TIME!
Date: Fri, 25 Feb 2000 11:27:36 GMT
On Thu, 24 Feb 2000 23:12:00 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>The square card you mentioned is called a turning grille. It is
>treated in old litteratures on cryptology.
And also on my web site at
http://home.ecn.ab.ca/~jsavard/pp0102.htm
------------------------------
From: Christof Paar <[EMAIL PROTECTED]>
Subject: Re: Implementation of Crypto on DSP
Date: Fri, 25 Feb 2000 07:03:13 -0500
On Tue, 22 Feb 2000, Douglas A. Gwyn wrote:
> [EMAIL PROTECTED] wrote:
> > I am working on a network crypto hardware card, and I would like to know
> > if there are any assembler libs ( 3DES, DH etc) for say Anolog Dev or TI
> > DSP .
>
> You don't really need to use assembly language on the TI TMS320C6x
> DSP; its C compiler does a very good job of optimizing to use
> multiple processing elements. (I have no experience with AD DSPs.)
ALthough the C compiler is pretty good, one can do much better with
assembly. At CHES '99 there was a paper by Itoh et al. describing a very
careful and optimized implementation of PK algorithms on the TI C62x @ 200
MHz. Here are some of the result they achieved (with rounded numbers)
ECC 192b RSA 1024b
sign 2ms 85ms
ver. 6ms 5ms
These numbers are very hard to achieve with plain C based on our
experience. On the other hand, of course, these numbers are very
impressive and one can get reasonably good results with C.
Cheers,
Christof
! WORKSHOP ON CRYPTOGRAPHIC HARDWARE AND EMBEDDED SYSTEMS (CHES 2000) !
! WPI, August 17 & 18, 2000 !
! http://www.ece.wpi.edu/Research/crypt/ches !
***********************************************************************
Christof Paar, Assistant Professor
Cryptography and Information Security (CRIS) Group
ECE Dept., WPI, 100 Institute Rd., Worcester, MA 01609, USA
fon:(508) 831 5061 email: [EMAIL PROTECTED]
fax:(508) 831 5491 www: http://www.ece.wpi.edu/People/faculty/cxp.html
***********************************************************************
------------------------------
Date: Fri, 25 Feb 2000 13:44:28 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Passwords secure against dictionary attacks?
JimD wrote:
> How about ten English words with different punctuation symbols
> as word separators?
Even with only spaces in between this would be okay, because there
are far too many possibilities for such keys that even fighting
them with a dictionary would not succeed. Only don't use some
sentence from a book, or else the attacker can still try to
use a libary (but at the moment, this would be hard to do).
Btw, such long passwords are called passphrases.
------------------------------
Date: Fri, 25 Feb 2000 13:52:16 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Crypto Speeds...
John wrote:
> I was looking for a basic framework for the encrypt/decrypt
> operations on my 500mhz PC. I have tested 1 million bytes and
> got 3000 microseconds. The encryption did 1000x1000. That is it
> called the encrypter 1000 times to encrypt 1000 bytes. I am
> aware that the calls to the encrypter take some time, but it
> shouldn't be much.
Whats that for a strange cipher which encrypts on a byte
basis, and needs 1.500 cycles (=3 ms at 500 MHz) for
each ?!? Modern symmetrical algorithms work on block
basis (for example, 16 bytes a time when using one of
the AES ciphers Mars, RC6(tm), Rijandel, Twofish, or
Serpent). Ciphers on byte basis will hardly be secure
at all....
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
