Cryptography-Digest Digest #919, Volume #9 Wed, 21 Jul 99 09:13:05 EDT
Contents:
Re: How Big is a Byte? (was: New Encryption Product!) (wtshaw)
Re: How Big is a Byte? (was: New Encryption Product!) (wtshaw)
Re: [Q] Finding K from P and C (wtshaw)
Re: (good) Calculator ("User")
Re: Replacing IDEA with Blowfish (SCOTT19U.ZIP_GUY)
Good Guy Hacker Needed (Rick Taylor)
Compression for encryption (SCOTT19U.ZIP_GUY)
Re: another news article on Kryptos (Jim Gillogly)
Re: X5X6 - "Keyless Encryption" is trademarked... (Steve Roberts)
Re: Q. Passphrase Key-Rate Authentication ([EMAIL PROTECTED])
AES Evaluation Code ("Brian Gladman")
Are Microsoft ASP session cookie easy to guess ? ("Gaudenzi Roberto")
Re: TLS and stream cipher padding ([EMAIL PROTECTED])
Traffic flow confidentiality (Thierry Moreau)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Tue, 20 Jul 1999 21:38:43 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> You can use base 1 by noting the implied addition between the successive
> digits of a number. E.g. 13 base ten implies 1*ten^1 plus 3*ten^0. In
> base one you have the same construction so that 1111 base one is 1*one^3
> plus 1*one^2 plus 1*one^1 plus 1*one^0 = 4 base 10. The powers all
> collapse and any number is represented by that many digits, all ones.
> Note that in base one there is no need for zero as there is no
> difference between powers, so no need for place holders.
>
I'm sure we can come up with special rules that will allow a base one, but
I notice you are forced to actually use the figure 1 in you system. In
base 10, there is not character for base ten, so you must use two that you
already have 1 and 0.
I see no problem with your power slant, that all the numbers would add up
to a sum, but the problem is in finding a character less than one that is
above zero which stands for an integer. Mathematics gets strange when you
work at its edges.
--
When I talk about running the bases, it's not baseball.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Tue, 20 Jul 1999 21:44:35 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> You can also be flamed for selecting which questions get male pronouns
> vs female pronouns. In one case I made selections randomly (now don't
> get excited), but when I published the document activists accused me of
> using female pronouns for the "dumber" questions.
>
"...And, God created man in its own image," might get people upset.
But, for sure, man created God in his own image, woman didn't.
I guess the problem with the Bible and religion is the often things are so
cryptic, and those seeking a single plaintext message cannot all agree
what it is. I suppose that like any good political document, the devil is
in the details.
--
When I talk about running the bases, it's not baseball.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: [Q] Finding K from P and C
Date: Tue, 20 Jul 1999 22:28:06 -0600
In article <7n31t0$p84$[EMAIL PROTECTED]>, "Sungmin Chun"
<[EMAIL PROTECTED]> wrote:
> Thanks for many comments.
>
> I am a beginner of the cryptography. I have two text books.
> "Applied Cryptography" by Schneier and "Handbook of
> Applied Cryptography" by Menezes, et al.
> But I cannot understand the 'known plaintext attack'.
> I have little knowledge of neccessary math(I majoring in elec. engg.)
> so that I can't understand how the 'known plaintext attack' can be done.
> Why some E(P,K) can be weak to the 'known plaintext attack' and
> others cannot?
>
Take something like a monoalphabetic system, if you have the ciphertext as
well as the plaintext, you have all the substitutions used.
There are systems where the key is not so difficult to get at. You are,
after all, trying to break the key in either case. The key could be much
larger, have many different alphabets than the example above. It would
require more information to solve it, and be comparatively stronger than
one alphabet.
There are systems where the key interacts with itself, making it harder to
recover, and requiring lots more information to solve than you might
otherwise anticipate. One of my weak ciphers, BLT, is like this.
Instead of using a normal sequence in a tableau, if the base sequence is a
deranged alphabet, not only are you trying to solve a repeating keyword,
but the sequence of the deranged alphabet as well. See the idea of key to
key interaction?
On up the scale, keys can interact with themselves and incoming data in
such ways as to make solution of them most difficult, impractical if not
impossible, making the cipher sort of like a black box that you cannot get
directly at.
--
When I talk about running the bases, it's not baseball.
------------------------------
From: "User" <[EMAIL PROTECTED]>
Subject: Re: (good) Calculator
Date: Tue, 20 Jul 1999 22:01:20 -0700
Vincent <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Does anyone know a soft running under Linux or Windows able to compute big
> number operations and to write the result either in decimal or in
> hexadecimal notation?
>
> Thank you.
>
>
You must have been hiding under a rock to not know about Virtual Calc :)
Virtual Calc 99
http://www.edepot.com/phl.html
THE MOST POWERFUL CALCULATOR IN THE WORLD!!!
The Win 95/98/NT calculator replacement.
============================================================================
----
Q: What is so special about Virtual Calc?
A: It supports infinite digits.
============================================================================
----
Q: How many digits is infinite?
A: 2147483645 digits.
To give you an example of how BIG 10^2147483645 is...
Number of books in Library of Congress: 10^8
Number of people in the world: 10^9
Number of particles (smaller than atoms) in universe: 10^79
============================================================================
----
Q: Is that all that is special about Virtual Calc?
A: NO!, it also supports unconstrained bases. YES! UNCONSTRAINED.
That means you are no longer limited by the common bases
(binary,octal,decimal,and hexadecimal). Virtual Calc supports
ANY!!! base from 2 on up. Try base 3, 4, 5, 20, 30, 40,
50, or ANY base you desire! No limits!!
============================================================================
----
Q: Is that all that is special about Virtual Calc?
A: NO!, it also supports "decimal" point, "binary"
point, "hexadecimal" point, "octal" point, and
ANY!! floating point from base 2 and up. Did you
know that all the calculators in the world support
ONLY the decimal point? Virtual Calc FREES you from
this constraint! Calculate floating point numbers
in ANY base you choose! 2, 3, 4, 64, etc. NO constraints!
============================================================================
----
Q: Is that all that is special about Virtual Calc?
A: NO!, it also supports infix expressions. Do you hate it when
you are calculating a lot of numbers, and have to start
over if you make a mistake? With Virtual Calc, you can
type the whole expression (77.632+(55/0.41)*333-2222.3+888
-12345.67*(987+345)) BEFORE you calculate. You can then go
back and modify a few numbers, punch calculate to see the
results instantly! No retyping!
============================================================================
----
Q: Is that all that is special about Virtual Calc?
A: NO!, it also supports customizable symbols for ALL
digits of ANY base, and ALL arithmitic operators!!
Example, you can customize digits 1234567890 to abcdefghij, and
+-*/ to !@#$, or ANY symbols you desire. Afterwards, if you
input abc!def, Virtual Calc will output egi.
(123+456=579) Virtual Calc frees you from symbolic
constraints!
============================================================================
----
Q: Is that all that is special about Virtual Calc?
A: NO!, Virtual Calc is FAST! So fast, it will shock
you. Try Adding, Subtracting, Multiplying, Dividing
100000+ digit numbers. No kidding. And it will get faster.
Virtual Calc 98 is NOT optimized. Future registered versions
will get even faster (We are talking many times faster, not a few percents).
============================================================================
----
Q: Is that all that is special about Virtual Calc?
A: NO!, Virtual Calc is a GUI calculator! It runs on
Windows 95/98/NT. Fully 32-bit. This is a Win95/98/NT calc.exe
replacement. Upgrade from the limited calculator in Win95/98/NT!
============================================================================
----
Q: Is that all that is special about Virtual Calc?
A: NO!, it also supports file loading and saving, clipboard
copying, and memory storages. That means you can edit the
numbers from any editor, and Virtual Calc can import it from
the clipboard or file, or store it locally in memory. It
can also export it to your favorite editor by saving to a
file or copying to the clipboard. This is useful because
Virtual Calc can handle HUGE numbers!!
============================================================================
----
Q: Why is this calculator so great?
A: The calculator uses state of the art algorithms
created from scratch. (It had to be, no other calculator
supports unconstrained bases and floating point, and ALSO
supports infix expressions and infinite digits!)
============================================================================
----
Q: I'm excited!!! How do I download it?
A: Visit..
http://www.edepot.com/phl.html
and download Virtual Calc 99 for Win95/98/NT!!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Replacing IDEA with Blowfish
Date: Wed, 21 Jul 1999 05:56:29 GMT
In article <7n35jv$deo$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>In article <7n2stc$220u$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>
>> >"somewhat" is right. IDEA uses multiplication, which is expensive
>> >in hardware (or slow). Feistel networks such as in Blowfish are
>> >far cheaper. Then again, in the case of Blowfish the large size
>> >of the key schedule hurts.
>> >
>> > paul
>>
>> actaully since IDEA use multiplicatiopn of a variable times a
>constant
>> each one of those could be repacled by a small 16X16 bit S table.
>> which is not so expensive.
>
>No, you need a 16+16-bit address and get a 16-bit lookup out.
>(You would be computing the product of two 16-bit ints
>modulo 2^16+1). But a 32 bit address is a rather large LUT.
NO you lack the basic understanding of how things work.
the input to the S table is 16bits not 32bits the table entries
are made from the constant part which comes from the key
or have you ever bother to actually look at IDEA.
Like I said before you need only a sigle 16X16 bit table for
each of the mutilplys but if you have not done much programming
it is understandable of your large lack of knowledge so don't
feel to stpuid.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Rick Taylor <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Good Guy Hacker Needed
Date: Tue, 20 Jul 1999 22:37:52 -0500
We need a good guy hacker to handle software and sourcecode encryption
efforts. Must have a VC++ background. This is a perm position in
houston.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Compression for encryption
Date: Wed, 21 Jul 1999 05:59:56 GMT
I presently have an adapative huffman compress that is suitable for
encryption. Will soon have a BWT type of compress that may be
better. So keep an eye out for it. Will add others if I get feedback.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: another news article on Kryptos
Date: Tue, 20 Jul 1999 22:10:25 -0700
Dave Salovesh wrote:
> Was there an announcement in 1992 when the NSA people solved the first
> three parts? From my warped perspective, the announcement was made on
> Monday in the Post.
No. My first clue was this June, when I called CIA and they sent me an
announcement of the talk David Stein gave over a year ago; in that announcement
it mentioned the NSA break and that he'd not known about it.
Since that time I've learned there is a "Kryptos Society" at NSA that
has newsletters and Christmas puzzles. I don't know whether it's open
to outsiders.
> At the risk of further revealing my ignorance, I thought I knew what
> Scheidt and Sanborn had publicly given as the background, yet I didn't
> know that the ciphers were known flavors until just now. Because of
> that missing fact, I was speculating that the last cipher was a
> completely home-grown variety or variation, especially suited to this
> exact plaintext and circumstance.
Roger -- the blurb the CIA had been sending out speculated (among other
wrong speculations) that the last part was one-time pad. We've learned
quite a lot since June.
--
Jim Gillogly
Sterday, 28 Afterlithe S.R. 1999, 05:04
12.19.6.6.16, 1 Cib 4 Xul, First Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Steve Roberts)
Subject: Re: X5X6 - "Keyless Encryption" is trademarked...
Date: Wed, 21 Jul 1999 06:22:13 GMT
[EMAIL PROTECTED] (John Savard) wrote:
>http://www.desktop-guardian.com/
>
>however, there is no description of the technique, or why it is
>"keyless", just that it is a block cipher that expands the message
>with some random content, not a PRNG stream cipher.
>On the off chance that this *isn't* snake oil - and from appearances,
>there's certainly a chance that it might not be - does anyone happen
>to know what it _is_? (A European patent _application_ is mentioned.)
>
John and others, this site has been up for a couple of years; I had
ambitions to sell it in Australia so I collaborated with the company
in a visit to the UK a year ago. So I do know a fair bit about the
cipher. There is a patent application and I have signed NDA's so I
don't want to go into details. Also I have not spent enough time on
it to be able to know what is really going on.
Essentially it uses streams of random numbers generated partly from
the sender and recipient addresses, partly from random numbers sent
with the message. There are also substantial quantities of random
salt thrown in with the text before encryption, so successive
encryptions are all different. I got about 90% of the way through
attacking it - but of course I could not complete the process and that
last 10% may well be secure. But overall I was not left with a high
degree of confidence that it would be secure against a serious attack.
Steve Roberts
Witham Pty Ltd
www.steveroberts.com.au
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Q. Passphrase Key-Rate Authentication
Date: Mon, 19 Jul 1999 12:33:56 -0400
Well, this is not EXACTLY what you are looking for, but I found myself trying
to figure out a way of making the secret ring of my program hard to brute
force. The way I devised was to hash the password, and then encrypt the hash
along with the private key using the user's password (unhashed). That way, if
an attacker wanted to brute force the password, they would have to decrypt the
secret key and the hash, hash the password, and test it against the real
hashed password. After thinking about it for a while, it really doesn't add
any security at all. All it does is make it take a bit longer to brute force,
and hopefully turn up some false positives. As for your idea of timing the
speed at which the phrase is typed, I would add a feature that would ask the
user weather or not he wanted it. B/c it may be more sucessful for some
people than others.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: AES Evaluation Code
Date: Wed, 21 Jul 1999 08:58:28 +0100
For those with an interest in the AES process my full Visual C++ AES
evaluation code is available at ftp.hacktic.nl as the file aes.zip in the
directory crypto/libs/aes. This package is quite large (~6MB) and
includes:
1. source code for all 15 candidates in C (with some use of extensions
such as fast rotates)
2. C++ code to generate and test against test vector files
3. C++ code to time the algorithms
4. sets of test vectors for each algorithm to check out the results
The code is not endian portable and is designed toi operate on an Intel
platform. I stress that this code is for AES evaluation purposes only
unless any of the designers of AES algorithms have explicitly allowed
wider expoitation.
enjoy
Brian Gladman
------------------------------
From: "Gaudenzi Roberto" <[EMAIL PROTECTED]>
Subject: Are Microsoft ASP session cookie easy to guess ?
Date: Wed, 21 Jul 1999 10:39:27 +0200
Microsoft ASP documentation states:
The following steps are taken when generating ASP session cookies:
- Session ID values are 32-bit long integers.
- Each time the Web server is restarted, a random Session ID starting value
is selected.
- For each ASP session that is created, this Session ID value is
incremented.
- The 32-bit Session ID is mixed with random data and encrypted to generate
a 16-character cookie string. Later, when a cookie is received, the
Session ID can be restored from the 16-character cookie string
(ASPSESSIONID).
- The encryption key used is randomly selected each time the Web server is
restarted.
Does anyone know more information about the algorithm used and the security
of this approach ?
How hard is to guess the value of an active cookie ?
thanks
Roberto Gaudenzi
N.C.H.
Bologna
Italy
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: TLS and stream cipher padding
Date: Wed, 21 Jul 1999 12:00:56 GMT
> > Why this padding was not contemplated for stream ciphers in TLS?
>
> This type of padding is not intended for "traffic flow
confidentiality".
> If your application really needs traffic flow confidentiality, you
> should look for traffic flow confidentiality padding (and even maybe
> encryption of addressing information ...).
First of all, I agree with Eric Young in that padding have been
considered in the design of TLSv1.0, so there might be something wrong
with SSL 3.0 padding.
Second, I'm not sure that "encription of addressing information" is
practical enought on Internet, if you mean encript by tunneling IP
datagrams, it is pretty expensive.
I don't know what you call "traffic flow confidentiality padding". To my
understanding, it this just padding.
Gabriel
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Thierry Moreau <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Traffic flow confidentiality
Date: Wed, 21 Jul 1999 08:09:27 -0400
I learned about traffic flow confidentiality from the ISO/JTC1-SC6
committee (Telecommunications and Information Exchange between Systems)
and the OSI Network Layer Security Protocol encompasses provisions for
it.
Briefly, trafic flow confidentiality is a "security service" that would
prevent someone from guessing even the level of traffic to/from a
subnetwork or end systems. E.g. hiding even the intensity of diplomatic
activity among external affairs departments of countries members of a
treaty.
When it comes to "security mechanisms", traffic flow confidentiality may
call upon padding, useless random datagrams (Protocol Data Units in ISO
parlance), and address hiding. Address hiding is used to send traffic
through a "black subnetwork" between two trusted network.
- Thierry Moreau
------------------------------
** 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
******************************
