Cryptography-Digest Digest #205, Volume #11 Sat, 26 Feb 00 21:13:01 EST
Contents:
Re: Cryonics and cryptanalysis (Tim Tyler)
Re: NIST, AES at RSA conference ([EMAIL PROTECTED])
Newbie Brute Force Question (Anthony L. Celeste)
Re: Implementation of Crypto on DSP ("Douglas A. Gwyn")
Re: NSA Linux and the GPL ("Douglas A. Gwyn")
Gyro Electronic Biometric url (Drew Cutter)
increasing key length through Hasing ([EMAIL PROTECTED])
Re: How to Annoy the NSA ("Douglas A. Gwyn")
Thoughts on biometric pen (Drew Cutter)
On jamming interception networks (Mok-Kong Shen)
Re: Cryonics and cryptanalysis (Jerry Coffin)
Re: On jamming interception networks ([EMAIL PROTECTED])
Re: On jamming interception networks (Andy)
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Cryonics and cryptanalysis
Reply-To: [EMAIL PROTECTED]
Date: Sat, 26 Feb 2000 20:54:35 GMT
Ralph C. Merkle <[EMAIL PROTECTED]> wrote:
: The major concern in cryonics is that the process of freezing will
: inflict sufficient damage that no future technology could reverse it.
: Indeed, it seems quite unlikely that the kind of methods currently
: employed in medicine would ever be able to restore a mammal frozen with
: current methods to an acceptable state of good health.
: The picture changes quite dramatically if we adopt the information
: theoretic perspective. The frozen person is now a high density analog
: storage medium which was subjected to an initial transformation. We
: seek to recover the healthy state ("plaintext") given the frozen state
: ("ciphertext") despite the effects of cryonic suspension ("encryption").
With cryptanalysis, the message may not contain all the information
necessary to decrypt it.
Sometimes there is more than one apparently-correct decrypt, and only
knowledge of the key can identify which message was intended.
If the key is lost, it may /never/ be possible to decrypt correctly.
So with freezing. Freezing is not completely lossless - information
relating to the living structure can be destroyed.
Undoubtedly a detailed analysis of the damage will eventually offer the
best hope of reconstructing something like the original document - but
what you refer to as "information theoretic death" /may/ already have been
caused by today's freezing processes.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
To iterate is human; to recurse, divine.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST, AES at RSA conference
Date: Sat, 26 Feb 2000 22:43:11 GMT
ch involve the list of acceptable ciphers should be fairly
> >> straightforward and we *can* test for those. What remains is the
> >> random selection process, which already had to be visited in system
> >> design anyway (for message keys). So I don't see a large
opportunity
> >> for error; this is a limited, well-controlled extension.
> >
> >It would be very usefull if you discuss in more detail your
> >implementation ideas. I agree with Tim that it makes perfect sense,
if
> >you have a handfull of good ciphers why not use them.
>
> This has been discussed. We have been having this particular thread
> for months, and there have been earlier threads and discussions
> probably for more than a year. I have a whole archived discussion
> from last year on my site. I have proposed having and using many
> ciphers for years.
>
> The first step is to make ciphers interchangeable. I think each
> "cipher" needs to have its own keying hash or equivalent which takes a
> key phrase into the internal keying. (Sometimes we will actually use
> a key phrase, but more often we will have stored or transient random
> sequence keys.) Message keys will be created and transported as
> usual, at a level above the ciphers per se.
>
> Different ciphers have different block sizes. Indeed, we might well
> want to include some stream ciphers in the mix (stream ciphers
> probably must include nonlinear mixing with state for confusion / data
> mixing rather than XOR). The higher system needs to choose the block
> size (and also support re-keying after some number of blocks). We
> also may need to have and choose RNG's.
>
> I suggest that there be no global numeric coding representing a
> cipher. Instead, each cipher should have a unique textual name. This
> avoids the need to have some central organization allocate and
> coordinate cipher numbers.
>
> Each end should have a list of ciphers they will accept for receiving.
Is each end an independent crypto application... or are both ends
running the same crypto software...
> Typically one end will send (along with the current message, but
> probably ciphered differently) the specification for the next desired
> cipher stack. The other end then uses those ciphers, or if not, just
> uses the old stack and sends back data and a response. The first end
> thus has exactly two choices of cipher stacks after any change: the
> specified stack and the old one. Error-detection indicates which is
> in force at the far end. If the change did not take, the far end
> probably sends back the list of ciphers it *will* accept. The option
> to force a particular cipher at a particular level probably implies a
> distinct list for each level. Meanwhile, the cipher may be being
> changed in the other direction as well. Ciphers might well change on
> a message-by-message or session-by-session basis. In practice, we
> expect each end to have and keep the list of ciphers acceptable to the
> other and to select from among them, thus requiring only the new
> selections and not a new "acceptable" list each time. The actual
> cipher selection would thus be made by index number within the list,
> thus minimizing negotiation overhead. We may want to send those
> numbers as text characters, however, instead of fixed-size fields.
>
Are you refering to a real time high bandwidth comms channel here, or a
low bandwidth channel e.g. simple email message. For the latter, I dont
see a need to negotiate which cipher to use...or maybe I am missing
something...you just encrypt with multiple ciphers and finally the
public key of the receiver and send it to the other end...very much like
an anon remailer chain...
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Anthony L. Celeste <[EMAIL PROTECTED]>
Subject: Newbie Brute Force Question
Date: 26 Feb 2000 17:08:05 -0600
Reply-To: [EMAIL PROTECTED]
I'm curious as to how long these brute force attacks take. Suppose you
have a well selected, long passphrase, encrypted with 3DES or
Blowfish. Approximately how long does a brute force attack take ? Is
it minutes, weeks, months ?
Also, I've seen some references here to RSA 2048 bit encyption, what
products are available that use this ?
Thnx, Tony
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Implementation of Crypto on DSP
Date: Sat, 26 Feb 2000 23:59:00 GMT
Joseph Ashwood wrote:
> Probably the biggest example I have against the "relatively
> little benefit" is a not so little known program called
> Quake II. When they rewrote a fairly small portion of it
> they saw a speed increase of around 400%, ...
Why do people conveniently ignore parts of a posting and
concentrate on others? What I said was:
>> 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.
That is compatible with programming Quake II in a higher-level
language and identifying a small portion that is performance
bottleneck, which is then recoded in assembly-language to exploit
special architectural features that aren't normally used by the
compiler (such as MMX instructions).
In the case of a mass-market product such as Quake II, the
volume of sales and use make it economically justified to
put a lot of effort into low-level tweaking, so long as the
release schedule is not unduly delayed. *Most* programs,
however, can't amortize the high cost of assembly-language
development across such a huge volume of sales.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA Linux and the GPL
Date: Sun, 27 Feb 2000 00:06:12 GMT
"John E. Kuslich" wrote:
> How can this guy get away with activities that would have landed
> the rest of us in jail for a long time?
I suspect it is too difficult to show that his actions amounted
to *theft* of government secrets, since it seems reasonable to
argue that he was merely conducting his normal job with the
material he had in his home. Do we know what safeguards he had
in place? (One would think that as DCI, he must have had full-time
bodyguards at the very least.) I bet the "rules" to which you
refer allow the DCI to grant special exemptions if he deems that
circumstances warrant.
Lyndon Johnson waved codeword documents in front of TV cameras,
but although in the IC we groaned about it, nobody thought there
was any chance of bringing any sort of punitive action against
the President. DCI is not much of a step down from President
in the IC hierarchy.
------------------------------
Date: Sun, 27 Feb 2000 19:03:24 -0500
From: Drew Cutter <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Gyro Electronic Biometric url
Looking for Gyro electronic url , biometrics pen ?
------------------------------
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: increasing key length through Hasing
Date: Sat, 26 Feb 2000 19:31:37 +0000
Hi, I'm a student working on an open source file encryption program,
well it will be open source once I've had the thing completed and
marked.
I tried to increase key length for user supplied keys that were smaller
than the maximum key length an algorithm could support. Below is the
source code for that section of code [from Borland C++ Builder] -=- if
anyone sees anything wrong with it or has a better way of doing
something similar then please get back to me.
-Emrul
/* If keysize entered is less than keysize of algoirthm, data needs
to be hashed to at least the length of KeySize.*/
if ((state.Key.Length() * 8) < CryptAlgoData->KeySize)
{
TRMD160Context RMDContext;
TRMD160Digest RMDDigest;
TSHA1Context SHAContext;
TSHA1Digest SHADigest;
long pos, x;
int KeyLength;
AnsiString TmpStr;
pos = 0;
KeyLength = Key.Length();
RMD160Init(RMDContext);
SHA1Init(SHAContext);
/*
1. Use RipMD160 Hash Algorithm to generate a 160bit
hash.
2. Feed the output of RipMD160 to SHA1 Hash algorithm
and
concatenate the ouput with the original input.
3. Repeat 1 and 2 until the number of bytes of hash =
the KeySize.
*/
do
{
RMD160Update(RMDContext, FinalKeyData, KeyLength);
RMD160Final(RMDContext, RMDDigest);
for (x = 0; x < 20; x++)
{
if (pos <= (CryptAlgoData->KeySize / 8))
{
FinalKeyData[pos] = RMDDigest[x];
KeyLength = pos;
pos++;
}
else
break;
}
SHA1Update(SHAContext, FinalKeyData, KeyLength);
SHA1Final(SHAContext, SHADigest);
for (x = 0; x < 20; x++)
{
if (pos <= (CryptAlgoData->KeySize / 8))
{
FinalKeyData[pos] = SHADigest[x];
KeyLength = pos;
pos++;
}
else
break;
}
} while (pos < (CryptAlgoData->KeySize / 8));
} /* End key initialisation*/
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How to Annoy the NSA
Date: Sun, 27 Feb 2000 00:11:38 GMT
[EMAIL PROTECTED] wrote:
> ... QC could be able to do new
> mathematical proofs or calculations that
> would take much too long to independently
> verify via a non-QC method.
How so? The main innovation in "doing mathematical proofs"
has been the method pioneered by Zeilberger and promoted by Wilf.
I don't see QC contributing all that much to the process.
------------------------------
Date: Sun, 27 Feb 2000 19:25:15 -0500
From: Drew Cutter <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Thoughts on biometric pen
Thinking using a biometrics pen for contracts , etc. Do I have to keep
a data base of signatures to verify that the signature is who sign the
document ? doing this wireless (palmpilot , window ce)?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: On jamming interception networks
Date: Sun, 27 Feb 2000 02:05:42 +0100
Recently in another thread I commented that interception networks
could be rendered inoperable if everybody of the world encrypts
his/her messages, whether text, voice or images, thus exhausting
the agencies' (huge but finite) computing resources to analyse
these.
In a private communication it was correctly pointed out to me that
my suggestion evidently entails too much work for the people to do
and hence the idea is useless practically. It was suggested
instead that everybody (it suffices, if there would be sufficient
number of people who cooperate) appends to his/her mails or posts
a few lines of random hex sequences. Since the agencies could not
know whether these are innocent 'scarecrows' or are outputs of
encryption algorithms, they would try to decrypt them. Since the
sequences, however, are in fact random, they can never succeed,
no matter how much efforts/resources are spent on them. On the
other hand, they can also never be sure that what they have in
hand are not secret messages, albeit encrypted with algorithms
of very high strength.
Thinking that this suggestion is indeed not too bad for practical
realization, I am presenting it here for discussions. Perhaps
some readers of this thread have cool and much better ideas.
M. K. Shen
==========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Cryonics and cryptanalysis
Date: Sat, 26 Feb 2000 18:00:45 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Cryonics and cryptanalysis might seem entirely unrelated.
>
> Cryonics freezes people when current medical technology is unable to
> keep them alive, with the hope that future technology will be able to
> restore them to good health.
>
> Cryptanalysis seeks to recover the plaintext from ciphertext despite the
> obscuring effects of encryption.
>
> What could possibly be more different? People are flesh and blood,
> cryptanalysis deals with bits and algorithms.
>
> But can people be described by bits? In the past several years, quite a
> few authors have pointed out that a sufficiently precise description of
> a human being -- a description in bits -- provides a "snapshot" of that
> human being at a specific point in time. Given the "snapshot," we could
> in principal restore the human being.
If (and pretty much only if) we can get to the point that anything we
can describe in the computer we can then create physically as well.
In this case, there would be no need to freeze the original body
though: you simply take the snap-shot, save IT and restore from it.
I think if you want to relate the two, there's a much more direct
relationship to consider. Think about this: right now, we have a
large and growing population. I consider it _highly_ likely that by
the time the technology is invented to cure diseases we currently
can't, that overpopulation will be an ever more serious problem than
it is today.
Therefore, the real trick to cryogenics accomplishing anything is to
give a motivation for people to bother un-freezing your body when a
cure is found for whatever disease you have.
One obvious way of doing that would be to invest some money in
something extremely stable, but encrypt the access to it so the only
way to get the money is for you to tell them the key. You memorize
the key and they can get the money by un-freezing you. This leaves
another problem though: somebody might wake you up even though they
haven't cured you. They torture/whatever you to get the key, and
then let you die.
To prevent that, what you probably want as a key is a combination of
three things: the result of a test showing you're disease-free, a
sample of your DNA to prove it's really YOU who's cured, and
something you've memorized, so they have to wake you up instead of
curing your body, but then just letting it die.
Note in particular that quite a few diseases are pretty easy to cure
if you don't mind killing the patient in the process: most forms of
cancer are _easily_ "cured" by sufficient doses of radiation. The
only trick is keeping from killing the patient along with the
cancer...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: On jamming interception networks
Date: Sun, 27 Feb 2000 01:53:11 GMT
> encryption algorithms, they would try to decrypt them. Since the
> sequences, however, are in fact random, they can never succeed,
> no matter how much efforts/resources are spent on them. On the
> other hand, they can also never be sure that what they have in
> hand are not secret messages, albeit encrypted with algorithms
> of very high strength.
I think that the sequences should be randomly taken from dictionaries and
encrypted with known algorithms. If they were pure random, weakness of
known encryption algorithms could serve as a means to distinguish between
random messages and actually encrypted ones.
Best regards,
Erich Steinmann
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Andy <[EMAIL PROTECTED]>
Subject: Re: On jamming interception networks
Date: Sun, 27 Feb 2000 13:02:33 +1000
Reply-To: [EMAIL PROTECTED]
Mok-Kong Shen wrote:
>
> [.. snipped ..] It was suggested
> instead that everybody (it suffices, if there would be sufficient
> number of people who cooperate) appends to his/her mails or posts
> a few lines of random hex sequences. [.. snipped ..]
>
> Thinking that this suggestion is indeed not too bad for practical
> realization, I am presenting it here for discussions. Perhaps
> some readers of this thread have cool and much better ideas.
>
> M. K. Shen
> --------------------------
> http://home.t-online.de/home/mok-kong.shen
Excellent idea. And just to wet their appetite, also
include a few interesting plain text words as well.
Bomb President Assassination IRA Carlos etc.
Regards
Andy
-- start message --
01E540E1 4E652B4B 1C79DC71 B06107CC F3D29F14 D4877244
2DCA0F04 0470EC52 D382EB83 12A9D158 90B87844 61FED0EE
D33842EB 3824160E 507E38B5 9515BBE8 D875B398 16070691
0D6D7582 35BD0C36 AC812096 CDEF1AF0 B681EA51 14DCA13B
210617F8 05E9F3E2 CA8B79EA E03D0D24 24B14DB2 5DD39CB0
B6A2038F 6809AA74 823E0961 2D56A38C 38293445 BA680EBD
AEA509EE C1B5AE59 C268A980 342825C2 054D50A8 5C2AF745
E6E85297 98C81B96 403BD1A4 E2109B03
-- end message --
------------------------------
** 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
******************************
