Cryptography-Digest Digest #14, Volume #11 Sun, 30 Jan 00 10:13:02 EST
Contents:
Re: NIST, AES at RSA conference (CLSV)
Re: "Trusted" CA - Oxymoron? (James Redfern)
Re: Security of Kremlin (PC software): Insecure implementation? (Michael)
Re: A question about odd grilles (John Savard)
Re: How much does it cost to share knowledge? ("Steve Sampson")
Re: Mac encryption algorithm? (Paul Schlyter)
Re: Security of Kremlin (PC software): Insecure implementation? (Paul Schlyter)
Re: Mac encryption algorithm - joke :-) (Paul Schlyter)
Re: Mac encryption algorithm? (Paul Schlyter)
Re: NIST, AES at RSA conference (CLSV)
Re: Intel 810 chipset Random Number Generator (Tim Tyler)
Re: NIST, AES at RSA conference (CLSV)
Re: Intel 810 chipset Random Number Generator (Tim Tyler)
----------------------------------------------------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sun, 30 Jan 2000 12:40:12 +0000
"Douglas A. Gwyn" wrote:
> CLSV wrote:
> > If breaking a cipher is equivalent to solving (a hard
> > instance of) a problem in NP and someone would prove
> > that P != NP then the cipher can not be broken with
> > polynomial effort.
> Any particular instance can be broken with O(1) effort.
> The argument you're trying to make applies only asymptotically
> as the "problem size" N becomes infinitely large.
Hmm, how do you break RSA with O(1) effort
if you can choose your primes as large as you
want?
Regards,
CLSV
------------------------------
From: James Redfern <[EMAIL PROTECTED]>
Crossposted-To:
alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss
Subject: Re: "Trusted" CA - Oxymoron?
Date: Sun, 30 Jan 2000 12:58:41 -0000
Reply-To: James Redfern <redfern[AT]privacyx[DOT]com>
In article <uIuj4.271$[EMAIL PROTECTED]>, jim@jim-
bennett.com wrote...
| But a CA *could* be trustworthy with proper procedures and
| insurance, right?
Could it? I have my doubts that the practical implications of this well
intentioned 'wish' are significantly beyond the capability of the average
user to encompass. And by average user, by definition, this includes not
only the average customer, but also the average operators in the banks,
financial institutions and everyone else in the chain.
JR.
--
James Redfern [redfern<AT>privacyx<DOT>com] The Redfern Organization
PGP key ID 0x8244C43A from <mailto:[EMAIL PROTECTED]?subject=0x8244C43A>
...ActiveNames delivers my undeliverable mail at <www.ActiveNames.com>
------------------------------
From: Michael <[EMAIL PROTECTED]>
Subject: Re: Security of Kremlin (PC software): Insecure implementation?
Date: Sun, 30 Jan 2000 14:19:10 +0100
> But there is something about it that concerns me. When I double-click an
> encrypted file (encrypted files are overwritten as *.kgb), I am prompted for
> a passphrase (key). If I enter an incorrect key, instead of decrypting the
> file to gibberish, it pops up a dialog that says "Incorrect Passphrase." I
> am no security expert, but it seems to me that in order for this software to
> know that my key is incorrect, it must be storing some information about my
> key in this .kgb file. Anyone have any thoughts on this?
>
> It might also be worth noting that Kremlin claims to apply SHA to the key
> before using it for encryption/decryption. Would this allow the scenario I
> described to be implemented in a way that would not put the key at risk? For
> example, if the hash value was stored in this .kgb file, which I assume must
> be the case.
There a a few ways of checking the key without actually storing the key.
I guess the method they choose is to store a hash (SHA1) of the key in
the file. When you enter your password, it's put through the SHA1 hash
function and the output is compared to the hash stored in the file.
Since a hash function is a one-way function there is no way (as we know
of :-) to extract the password from the hash.
You can get the hash from the password, but not the other way round.
Since the SHA1 is a 160 bits hash function, there is no danger that
anyone will ever find a password that will hash to the same value as the
password you have choosen, so this method is very secure and also most
widely used.
Another way is to encrypt the password with the password itself and
store this in the file. When you enter your password, the password in
the file is decrypted and then compared to the password you entered. If
the two passwords are the same, then you have entered the correct
password.
On a final note... when you enter your password, it's always put through
a hash function before being used for encryption/decryption. This is
because if the algorithm uses eg. 128 bit keys, you need to generate 128
bits of data from the password you type.
Bottom line... The approach that this program uses, is the same as
almost any encryption software, and is considered secure.
--
IMPORTANT NOTE:
To reply by e-mail you MUST include the word I-ACK in the subject
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: A question about odd grilles
Date: Sun, 30 Jan 2000 13:17:46 GMT
On Sat, 29 Jan 2000 23:23:56 -0600, [EMAIL PROTECTED] (wtshaw) wrote,
in part:
>A triangle grille looks interesting as well. I understand there was a
>writeup about one in 1947. Maybe someone has the issue. The grilles will
>be interesting to program, which is what I really like to take as a
>challenge.
And, of course, if the central hole is treated as in a square grille
with an odd side, one can also do a hexagon grille:
1 2 3 1
3 4 5 4 2
2 5 6 6 5 3
1 4 6 X 6 4 1
3 5 6 6 5 2
2 4 5 4 3
1 3 2 1
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: "Steve Sampson" <[EMAIL PROTECTED]>
Subject: Re: How much does it cost to share knowledge?
Date: Sun, 30 Jan 2000 08:13:43 -0600
Not true. There was an active group of people who had PDP-8
computers, and various other machines. This was way before the
8008. I thought the PDP-8 was a fine machine, but the Z-80
finally blew it away in performance. IBM came way, way after,
with the 8080. But that's where the PC name came from. Prior
to that, they were microcomputers. Hackers were good guys until
the media used the term to identify the criminal element. Same with
the word "Gay." Isn't it sad, how a beautiful word like gay, got
turned into a synonym for f**king boys in the ass? All from the
media giants...
If ENIAC was a personal computer, then the PDP-11 could be
considered a lap-top...
Rick Braddam wrote
> > > That actually makes sense, because if there hadn't been any hackers,
> > > there would be no PC's either, because the personal computer
> revolution
> > > started among hackers.
> >
> > Not really. You may be thinking of the Apple/Apple II, or even
> > IMSAI, but we had personal interactive computers as far back as
> > ENIAC. The "PC" in the Intel x86 sense originated with IBM,
> > hardly known as "hackers".
>
> I don't know what Paul is thinking, but his post reminds me of two
> construction projects that appeared in electronics hobbiest's magazines
> in January, in (I think it was) 1975. One was in Radio-Electronics, the
> other in Popular Electronics. Both used the Intel 8008 eight-bit
> microprocessor. Seems like one was called Mike-8, and the other Elf-8,
> but I'm not sure about the names.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Mac encryption algorithm?
Date: 30 Jan 2000 14:26:08 +0100
In article <87034j$hjt$[EMAIL PROTECTED]>,
Vernon Schryver <[EMAIL PROTECTED]> wrote:
> In article <86viki$8bu$[EMAIL PROTECTED]>,
> Paul Schlyter <[EMAIL PROTECTED]> wrote:
>
>> ...
>>> That is a religious view without factual basis. Regardless of byte order,
>>> your compiler and everything else must continually take the width of
>>> numbers into account.
>>
>>Not always, on little-endian machines...
>
> Yes, "so," except when you're coding bugs.
> What are C prototypes and Fortran function declarations
WHAT FORTRAN function declarations? <g> (I quit using Fortran back
in 1985 or so, and know very little about Fortran-90)
> except the top of the iceberg of continually takikng the width of
> numbers into account?
Again, you're focusing on syntax, not semantics.
It's of course a Good Thing to do type checking as much as you possibly
can. But at some stage, the type checking and conversion must
result in some actual code. If you want to convert a larger integer
type to a byte by picking the lowest order byte only, on a big-endian
machine, there must be code to shift to that lowest order byte, at
the end of the integer. On a little-endian machine, no extra code
must be produced, since the lowest order byte already is situated
at the beginning of the integer.
>>> It makes no real difference whether you increase an index to get to
>>> the more significant bits of a number, or decrease the index.
>>
>> Well, the point here is that on little-endian machines you don't need
>> to decrease the index.
>
> When calling by value, you don't increase or decrease any indeces on either
> byte order for small values (<= 8 bytes). When calling by reference, when
> narrowing a wider value, and coding a bug, you need to increase (not
> decrease) the address.
Correct - I made a typo above, it should be an increase of the address.
> How often does that happen in non-buggy code?
I have no statistics of this, but I believe it happens more often
than you think. But perhaps you'd call each and every such occurrence
a "bug"? It's a "bug" only if you don't know what you're doing, and
if it can produce some undesirable side effect.
>>Suppose you have a function which needs one byte as an argument, and
>>it receives a pointer to that argument. Also suppose that when
>>calling that function, you could pass a byte, a short integer, or a
>>long integer. Now what will happen?
>>
>>On a big-endian machine, the function must somehow be made aware of
>>the type of the argument, and must then increase the byte index as
>>needed. Alternatively, the code for calling this function must first
>>convert the argument to a byte, before passing a pointer to it to the
>>function, if the original argument is wider than one byte.
>>
>>On a little-endian machine, the function merely grabs the byte
>>pointed to by the pointer. And the code calling that function need
>>not do any type conversion, since the low-order byte will be first,
>>no matter if the argument is a short or a long integer. The result
>>will be somewhat smaller code size and somewhat faster execution.
>
> That is true only if you are calling by value
I'd call that "call-by-reference" though....
> and coding a bug or
> being too clever by half (i.e. writing bad code that only works
> for now). In either big or little endian systems, what happens
> when the called function increments the called-by-reference value?
> Does the wide result back in the calling function make sense?
You know it doesn't -- and if this methodology is used, the byte
should only be accessed, not modified.
> Yes, in languages where you can declare a formal parameter read-only, that
> would not be a bug, but a reasonable implementation of such a language
> will go ahead and pass the value in a register, and so calling by value.
>
> How many languages do you use that use call-by-reference?
I used FORTRAN prior to 1985 and Pascal prior to 1990. C/C++ and
friends allow call-by-reference, although you must do it explicitly,
by passing a pointer.
And in assembler, you'll of course have complete freedom to implement
parameter passing (to functions not called from any HLL) anyway you
like.
> Do you know that C and relatives call by value,
:-) ....yes, I've known that since 1981....
> that all reasonable systems
> pass most call-by-value args in registers, that they fill those registers
> with single instructions in either byte order, and need the same number
> of instructions to pass values on stacks? (Yes, I guess I'm saying 80*86
> is now unreasonable. Mercede implies that Intel agrees.)
>
> How much Fortran code have you seen that passes bytes to functions
> that expect wider numbers?
Too much -- I've seen many horrors in Fortran, mostly due to the fact
that it's missing function declarations...
> If big endian code is bigger and slower, then the effect should be
> noticable. If so, how is it that the fastest Fortan systems have
> long been big-endian? Below the old "super computer" class, how
> did the many big-endian "high performance workstations" manage to
> clobber the performance of all little endian systems starting about
> 1983 and continuing until now? (My answer to that is "because byte
> order doesn't matter, but other things do.")
...and if these systems had been little-endian and not big-endian,
these systems could have been faster still.... <g>
--
================================================================
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] (Paul Schlyter)
Subject: Re: Security of Kremlin (PC software): Insecure implementation?
Date: 30 Jan 2000 14:46:35 +0100
In article <[EMAIL PROTECTED]>,
cedric frost <[EMAIL PROTECTED]> wrote:
> But there is something about it that concerns me. When I double-click an
> encrypted file (encrypted files are overwritten as *.kgb), I am prompted for
> a passphrase (key). If I enter an incorrect key, instead of decrypting the
> file to gibberish, it pops up a dialog that says "Incorrect Passphrase." I
> am no security expert, but it seems to me that in order for this software to
> know that my key is incorrect, it must be storing some information about my
> key in this .kgb file. Anyone have any thoughts on this?
There are plenty of ways to implement this. One way is to, before
encryption, add a header or a footer, with known contents, to your
file before it's encrypted. After decryption with a bad key, the
header or footer won't contain what's expected, and the program then
knows the key was wrong.
Another, more secure, way is to append, or prepend, your file with a
hash of some kind, e.g. an MD5 or SHA, before it's encrypted. After
decryption, the hash is checked -- if it's bad, then either your key
is bad, or the encrypted file has been modified somehow.
--
================================================================
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] (Paul Schlyter)
Subject: Re: Mac encryption algorithm - joke :-)
Date: 30 Jan 2000 14:49:11 +0100
In article <[EMAIL PROTECTED]>, Andy <[EMAIL PROTECTED]> wrote:
> I went to a new restaurant for a curry the other day. I was
> supprised that they served the desert first, then the vindaloo,
> and finally the poppadams. When I paid the bill (check), I asked
> why the meal was served backwards. The waiter said "Didn't you
> know sir? This is a little Indian restaurant". Tee hee.
My kids would love that -- they *always* ask for the dessert first! :-)))
However, one thing puzzles me in your story: you paid the bill AFTER
the meal instead of BEFORE, on a LITTLE Indian restaurant? How come?
On a true little Indian restaurant, you must do things in this order:
1. Exit the restaurant
2. Pay the bill
3. Eat dessert
4. Eat mail meal
5. Eat aperitif
6. Wait for meal
7. Order meal
8. Enter the restaurant
9. Phone the restaurant to reserve seats
10. Check which little Indian restaurant you'd want to dine at
Right? :-)))
Anyway, be sure you visit a BIG Indian restaurant the next time.. :-))))))
--
================================================================
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] (Paul Schlyter)
Subject: Re: Mac encryption algorithm?
Date: 30 Jan 2000 14:26:48 +0100
In article <87085u$kr9$[EMAIL PROTECTED]>,
Vernon Schryver <[EMAIL PROTECTED]> wrote:
> In my experience, mixed-endian or bi-endian anythings tend to be like most
> comprises, worse than than either honest choice. There have been many
> other less than wonderful choices for hardware floating point hardware
> before IEEE 794, choices that required large to small software gyrations.
> Examples that spring to mind include the crazy IBM exponents and the
> incredible CDC (and I think also Cray) rounding modes.
Related note: the CDC even used one's complement to represent negative
numbers, not only for integers but for floating-point numbers as well!
> Are you are saying that big endian floating point on a big endian machines
> are necessarily noticeably slower or faster, more or less awkward, and/or
> noticeably require more or fewer instructions for reasonable code for
> reasonable languages than little endian floating point on little endian
> machines in the equivalent situations?
Floating point is a whole different animal. The advantage of
little endianness is noticeable only on some integer operations.
On floating-point operations they vanish.
> If so, then until you offer far
> more explicit reasons, and certainly reasons unrelated to mixed-endian
> chimeras, I'll continue to believe you're expressing a mere religious
> preference.
Look who's talking.... <g>
--
================================================================
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: CLSV <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sun, 30 Jan 2000 14:58:45 +0000
John Savard wrote:
>
> On Sat, 29 Jan 2000 22:10:37 +0000, CLSV <[EMAIL PROTECTED]> wrote:
> >[...] there are ciphers based on problems like the RSA-problem
> >that are conjectured to be equivalent to hard problems.
> >It is not unreasonable to think that in the future
> >ciphers will be developped the breaking of which is
> >proveable equivalent to solving a hard problem.
> There are already such ciphers.
> That isn't the problem.
> The problem is proving that the "hard problems" actually _are_ hard.
> *That's* what's equivalent to solving the halting problem.
I'm affraid I don't follow your reasoning.
The halting problem for Turing machines can
not be solved (in its normal context). Finding a
reduction between for example the RSA problem and
some hard problem known to be in NP might be
possible. I don't see the equivalence
between the halting problem and proving the strength
of a cipher by finding a reduction to an NP problem.
One is impossible to solve the other might or might
not be.
Regards,
CLSV
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Intel 810 chipset Random Number Generator
Reply-To: [EMAIL PROTECTED]
Date: Sun, 30 Jan 2000 14:56:41 GMT
Vernon Schryver <[EMAIL PROTECTED]> wrote:
: As far as I know, the only method Mr. Kagalenko has come even slightly
: close to proposing seemed to involve measuring the drift of a personal
: computer's clock compared to high precision clocks via the Internet. []
...though it appears that another crystal clock in the same enclosure
would do almost as well.
The temperature fluctuations under discussion are generated at least
partly by factors internal to the crystals. In other words a shared
ambient teperature would reduce - but not eliminate - the noise present
in the crystals.
It's not easy for me to believe that getting random numbers via this route
would produce a very rapid stream, since crystal oscillators are designed
to *minimise* the component of random noise.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Smoking cures weight problems eventually.
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sun, 30 Jan 2000 15:06:48 +0000
John Savard wrote:
> Will a program that generates successive primes by the Sieve of
> Eratosthenes method, using the part of the tape that goes off to the
> left, and writing down on the part of the tape to the right all the
> twin primes it finds while doing that, go beyond any finite point on
> the right side of the tape?
> Such a program can be modified so that it halts once it moves past
> cell 2^(2^(2^1000))) on the right side of the tape, so at least the
> question "Are there more than N twin primes" for any finite N can be
> phrased in the form of the question "will this program halt".
> A program that halts after doing a brute-force-search for
> counterexamples to Fermat's Last Theorem can be constructed directly,
> without this little correction.
> Now, think of a genetic algorithm that halts when it cooks up a
> program to crack DES that is more efficient than a certain pre-set
> goal...
What do you want to say? There is an infinite class of programs
for which an algorithm can be written that decides if a program
from that class halts or not.
Regards,
CLSV
------------------------------
Crossposted-To: sci.physics
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Intel 810 chipset Random Number Generator
Reply-To: [EMAIL PROTECTED]
Date: Sun, 30 Jan 2000 15:00:00 GMT
In sci.crypt james d. hunter <[EMAIL PROTECTED]> wrote:
: The thing with random is that you actually -build- one,
: instead of yapping about them, you will make some money.
: Since you didn't make one, it has to assumed that you
: don't understand what you're saying.
This argument has no logical foundation, AFAICS.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Some things have to be believed to be seen.
------------------------------
** 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
******************************
