Cryptography-Digest Digest #603, Volume #9 Thu, 27 May 99 14:13:02 EDT
Contents:
Authenticating identity? ([EMAIL PROTECTED])
3-DES test vectors (Mark Chimley)
Re: Review of Scottu19 (Thomas Pornin)
Re: Why would a hacker reveal that he has broken a code? (Terry Ritter)
X.509 (Efthymios Ntasis)
Re: NSA proves banks use poor crypto (Ronald Benedik)
Re: Why would a hacker reveal that he has broken a code? (Paul Schlyter)
Re: Stream Cipher using LFSRs ([EMAIL PROTECTED])
Re: Review of Scottu19 (Thomas Pornin)
Re: Authenticating identity? (Medical Electronics Lab)
Re: RSA Cryptography Question ([EMAIL PROTECTED])
Re: RSA Cryptography Question ([EMAIL PROTECTED])
Re: block ciphers vs stream ciphers ("Douglas A. Gwyn")
Best algorithm combination? (Kiril Kesarev)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Authenticating identity?
Date: 27 May 1999 08:04:50 -0700
Hi all,
I'm looking at cheap ways to authenticate the identity of the
sender of a message.
There are two individuals, Dick & Jane. Each can publish a small amount of
information that seldom changes. They have no shared secrets.
Dick sends a message to Jane, and Jane wants to be able to prove that
the message came from Dick. I'm not trying to sign the contents of the
message, just include a cookie that proves that it came from Jane.
It's a one-way transaction: there's no handshaking and no data passes
from Jane to Dick during the sending of the message from Dick to Jane.
One obvious solution is for Dick and Jane to both publish public keys, then
Jane takes Dicks public key, encrypts it with her private key and includes
the result in the message. Dick then decrypts the cookie with Janes public
key, and if he gets his own public key he knows it came from Jane.
Does any simpler scheme spring to mind?
And, if not, any thoughts on the appropriate PK system for this sort of
setup? (usual provisos - legally unencumbered would be nice).
Cheers,
Steve
--
-- Steve Atkins -- [EMAIL PROTECTED]
------------------------------
From: Mark Chimley <[EMAIL PROTECTED]>
Subject: 3-DES test vectors
Date: Thu, 27 May 1999 16:52:21 +0100
Has anyone please got any 3-des test vectors? i.e plain-text, keys and
resulting cypher-text that would be generated by a correct 3-des
implementation
--
Mark Chimley
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: Review of Scottu19
Date: 27 May 1999 14:23:44 GMT
According to SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>:
> I feel that the NSA has advanced quatun computers
It seems to me that brain wave analyzors are much easier to build and
operate than advanced quantum computers. Considering that such devices
completely anihilate the whole purpose of cryptography, I really do not
care about NSA quantum computers.
Among other cool devices that could be built more easily than quantum
computers, there are:
-- artificial flies with cameras
-- truth serums that make you reveal anything you know, without you
remembering anything of this event
-- cloning factories, to make reproductions of your beloved and trusted mom
And, more important, there already officially exists devices that detect
waves broadcasted by keyboards and screens: anything you see on your
screen, anything you type can be easily known (in real-time) 200 feet
away. Protection against this sort of things is not easy.
All this does not even take into account all backdoors that may have been
introduced in your processor.
To sum up: it is rather illogical to assume that the NSA has an extreme
technological advance wrt quantum computing, but no such advance in all
others domains. If only protection against quantum key searcher was
cheap, then why not ? But your algorithms show that this protection is
expensive. scott19u is really not suitable for on the fly encrypting of
a harddisk.
--Thomas Pornin
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Why would a hacker reveal that he has broken a code?
Date: Thu, 27 May 1999 16:40:53 GMT
On Thu, 27 May 1999 14:19:00 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>[...]
>I'm not trying to say that everything must be insecure, although I
>acknowledge the validity of Terry Ritter's point on the other hand:
>even when a cipher _is_ secure, it's very hard to *prove* that it is,
>since somebody could have an analytic method of attack of a kind that
>we hadn't even begun to think of.
I think everybody agrees with that, but in cryptography there seems to
be some sort of peculiar need to go *beyond* what science and logic
can deliver.
Not only does the collective experience of cryptanalysis not rise to
the level of proof, it is not even "evidence" of what others can do.
>It's sort of like trying to predict what mathematicians will discover
>next year.
Notice that what mathematicians work on and fail to find this year is
*not* treated as "evidence" of a limit on what math dabblers could do,
what other groups might already have done, or what will happen next
year.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Free Encrypted Email www.hushmail.com [EMAIL PROTECTED]
------------------------------
From: Efthymios Ntasis <[EMAIL PROTECTED]>
Subject: X.509
Date: Thu, 27 May 1999 14:07:03 +0300
I would like to make a CA publishing public key certificates following
the X.509 specification. Could you tell me which should be the format
of the certificates, having in mind that my system is quite simple,
having
just one CA for the moment?
I have a description of the X.509, but is there an example of such a
structure
and which fields would you recommend me to use?
Thanks in advance.
Efthymios Ntasis
[EMAIL PROTECTED]
------------------------------
From: Ronald Benedik <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: NSA proves banks use poor crypto
Date: Thu, 27 May 1999 18:57:43 +0200
Steven Alexander wrote:
>
> Even though this story comes from a respected source, it is highly
> questionable. Foreign countries would have a serious problem with a U.S.
> government agency attacking foreign banks.
I don`t know of any bank outside the U.S. implememting more than the
standard (i guess 56 bit) banking encryption. At least not in Austria.
If they were using the new high tech availavle then why the Y2K problem?
Why not taking his money from a bank in switzerland?
What can they do if this is successful?
nothing.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Why would a hacker reveal that he has broken a code?
Date: 27 May 1999 18:09:17 +0200
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
> Wesley Horton <[EMAIL PROTECTED]> wrote, in part:
>
>> Just as a matter of question, roughly how long would it take a new 550
>> mhz Pentium to do an exhaustive key search on single DES?
>
> Way too long. Hundreds of years? Perhaps a bit less.
Much more, unless that PC is equipped with dedicated DES hardware.
To do an exhaustive search in 1000 years, one would have to try
some 2 million DES keys every second. That's probably too much
for even the latest fastest Pentium.
> (But a $250,000 customized system can do it in weeks, as was
> recently proven.)
Yep -- and such a system will have to use dedicated DES hardware.
The DES algorithm was designed for hardware -- software
implementations of DES are quite slow.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Stream Cipher using LFSRs
Date: Thu, 27 May 1999 16:44:25 GMT
[EMAIL PROTECTED] wrote:
> I have been looking at stream ciphers using LFSRs and I have a idea.
I
> called it SCP (Secure Communication Protocal, which is an
> assumption...). It's based on the difficulty of finding the factors
of
> numbers in prime fields.
What is the purpose of these projects? They producing
atrocious ciphers, and you could learn about crypto
much more efficiently by reading and working some
exercises.
In a field, all the non-zero elements are units, so
I'm not sure what "the difficulty of finding factors
in a prime field" means. We can say a is a factor of
x iff there is some b such that a*b = x. Now for any
x in the field, _all_ the elements are factors, which
makes them kind of easy to find.
> For example two 8-bit values are multiplied and the output is the
> remainder divided by 257 (ab mod 257).
So what is the difficult problem here?
--Bryan
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: Review of Scottu19
Date: 27 May 1999 16:48:12 GMT
According to SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>:
> C is meant so that programers can code quickly from one machine
> to another but it lacks many features that would be of use to a
> encryption programer. For example ASCII C does not have a nice way of
> speciifing number of bytes per variable.
ANSI, not ASCII.
Actually, C has some requirements for the length of integer variables,
that are not expressed in terms of bytes (there used to be machines
where bytes did not even exist).
Typically, the integer types may represent values in the following
ranges:
min max
char 0 127
signed char -127 127
unsigned char 0 255
short -32767 32767
unsigned short 0 65535
int -32767 32767
unsigned int 0 65535
long -2147483647 2147483647
unsigned long 0 4294967295
When you cast an integer value to another integer type, and the value
is in the two ranges, then the value is kept. Otherwise the result is
(mostly) undefined ("the computer catches fire" is a legal behaviour
in such a case -- more reastically, there are compilers where such an
attempt is sanctionned by an end-of-task).
There is no obligation for signed integer to be represented in
two's complement. Actually there are computers which do use other
representations (one's complement, or positive mantisse and a sign bit),
which explains that (for instance) the lowest representable value in
an int is -32767 and not -32768. There is also no obligation on what
happens in case of overflow (if an int contains 32767 and you add 1,
everything can happen, included an automatic installation of win98 --
although this is not probable).
However, unsigned integers are guaranteed to be rounded up modulo a
power of two in case of overflow. If you add 1 to an unsigned int
containing 65535, the result will be 0 + k * 65536, where k is 0 or 1,
depending on the implementation (and the computer must not catch fire).
So, given these characteristics, I have yet to see a single crypto
algorithm that cannot be implemented in an elegant, readable and
notwithstanding fast way in a true ANSI C fashion. See that memory
representation is completely irrelevant here: if the computer decides
to store a value in decimal, it is its problem, not yours.
The potential limitations of ANSI C are:
-- No integer type for unsigned values bigger than 32 bits. This will be
corrected in the next ISO C specification (the so-called C9X, which will
probably be C2K after all), which will standardize the "unsigned long
long".
-- No way to take some benefit of the ability of some processors to
generate the upper bits of a multiplication: if you multiply two
unsigned longs, you only get an unsigned long. But an Intel CPU produces
a 64 bits quantity in this case, and you have to include some assembly
to get the 32 higher bits (or otherwise use the unsigned long long).
Same applies to Alpha processors (there is an opcode that outputs the 64
high bits of a 64x64 multiplication).
These two limitations strucked us when DFC (an AES candidate) had to be
implemented (in DFC there are arithmetic operations on values modulo
2^64+13, including a multiplication). The consequence is that, on a PC,
the true ANSI C version is somehow 4 times slower than a completely
hand-optimized assembly version. This is really not worth ranting about:
if you want absolute speed, you would go for assembly, but properly
coded C is portable and this is really valuable. The same, exactly the
same C code will run unchanged on Sparc, UltraSparc, Intel, Alpha,
680x0, PowerPC, Vax, PDP, 6809, Z80,... Think about smartcards for
instance.
And, more important, the DFC ANSI C code is understandable. This is not
so relevant because DFC comes with a real description anyway, but at
least one may read it and have some confidence.
As for endianness, it is completely irrelevant. If your input data
is an array of unsigned chars, use a macro to get these as 32 or 64
or whatever bits, in the endianness you prefer, and let the compiler
optimize the operation, depending on the architecture. It is much better
than you and me anyway.
To sum up all this: there is one advantage in producing C code that is
not ANSI C compliant. Namely speed. But there are major drawbacks, worst
of them is the lack of readability (which is bad for a symetric cipher,
since the only real security you may get is derived from public review:
many smart people read it, nobody breaks it, so it must be secure -- I
have much more confidence in RC5 than in any of your algorithms, for
this very one reason). Another drawback is that it makes you appear as
perfectly incompetent in coding. This also is bad for confidence.
--Thomas Pornin
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Authenticating identity?
Date: Thu, 27 May 1999 12:23:34 -0500
[EMAIL PROTECTED] wrote:
>
> Hi all,
>
> I'm looking at cheap ways to authenticate the identity of the
> sender of a message.
>
> There are two individuals, Dick & Jane. Each can publish a small amount of
> information that seldom changes. They have no shared secrets.
>
> Dick sends a message to Jane, and Jane wants to be able to prove that
> the message came from Dick. I'm not trying to sign the contents of the
> message, just include a cookie that proves that it came from Jane.
>
> It's a one-way transaction: there's no handshaking and no data passes
> from Jane to Dick during the sending of the message from Dick to Jane.
>
> One obvious solution is for Dick and Jane to both publish public keys, then
> Jane takes Dicks public key, encrypts it with her private key and includes
> the result in the message. Dick then decrypts the cookie with Janes public
> key, and if he gets his own public key he knows it came from Jane.
>
> Does any simpler scheme spring to mind?
>
> And, if not, any thoughts on the appropriate PK system for this sort of
> setup? (usual provisos - legally unencumbered would be nice).
The real trick here is that they both know they have the other's
public key. As long as *that* part is exchanged correctly, then
you can easily authenticate. If you are certain that you can
do that securely and authenticly, then the scheme you suggest
should work.
You can find unencumbered code here: http://www.terracom.net/~eresrch
and full documentation here: http://www.manning.com/Rosing
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA Cryptography Question
Date: Thu, 27 May 1999 17:15:37 GMT
John Savard wrote:
> "HypSoft" <[EMAIL PROTECTED]> wrote, in part:
>
> >Does anyone know the reason that the RSA algorithm's encrypting
process is
> >one-to-one?
>
> If you take a number that is relatively prime to the modulus, then if
> you keep multiplying it by itself, you have to go through all the
> possibilities before coming back to the start.
I think you're confusing a "generator" and "relatively prime".
Try 2 in the multiplicative group mod 3*5.
--Bryan
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA Cryptography Question
Date: Thu, 27 May 1999 17:23:07 GMT
HypSoft asked:
> Does anyone know the reason that the RSA algorithm's encrypting
process is
> one-to-one?
You've gotten a few answers, but I'll add one more.
The standards for RSA encryption require some random
or pseudo random bytes in the block that becomes the
base for the exponentiation. That makes the
(message, ciphertext) relation one-to-many.
--Bryan
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: block ciphers vs stream ciphers
Date: Thu, 27 May 1999 17:59:40 GMT
cairus wrote:
> It seems that today the cryptographic community
> is much more interested in block ciphers than in
> stream ciphers. Which is the reason for this trend?
You must mean the open crypto community, because that's not true
in general -- military and diplomatic systems tend to be stream
oriented.
I think the main reason for the interest was the publication of
DES, which was for some time the only relatively high-grade
cryptosystem whose details were available for public study.
Another reason was the development of "public-key" systems,
which typically (e.g. RSA) operate on a single large integer,
thus "block". Number theorists tend to be more comfortable
working with isolated instances than with continual processes.
------------------------------
From: Kiril Kesarev <[EMAIL PROTECTED]>
Subject: Best algorithm combination?
Date: Thu, 27 May 1999 20:44:20 +0300
Several ciphers can be combined to increase security. One
scheme would look as follows:
1. Split the message into N shadows by XORing it with bits
from a true RNG. Each shadow has the same length as the
original message and all shadows are required to reconstruct
the original message (OTP-style).
2. Each shadow is encrypted separately with different
secret-key ciphers using different keys for each of them.
3. The resulting ciphertext will consist of all the
encrypted shadows.
In order to break the scheme, a cryptoanalyst must be
able to break all the secret-key ciphers used in the scheme.
If a paranoid person wishes to encrypt his email using
several secret-key algorithms in parallel, what combination
of ciphers should he use?
Is it wise to bet on one type of ciphers, eg. encrypt
using 3DES, IDEA, and BLOWFISH, or use a diverse combination
like: BLOWFISH, some LFSR-cipher, RC4, and a strong PRNG such as the
BBS-generator?
Any ideas on the "best" combination of ciphers?
--
Kiril Kesarev <[EMAIL PROTECTED]>
------------------------------
** 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
******************************
