Cryptography-Digest Digest #4, Volume #11 Sat, 29 Jan 00 21:13:01 EST
Contents:
Re: ascii to binary ("Adam Durana")
Re: Mac encryption algorithm? (Vernon Schryver)
Re: Is there a practical guide to using crypto? (John Savard)
Re: Help needed on peculiar use of cryptography (John Savard)
Re: NEC claims New Strongest Crypto Algor ("Douglas A. Gwyn")
Re: Q: DFT ("Douglas A. Gwyn")
Re: A question about odd grilles (John Savard)
Re: Anyone read this book? (John Savard)
Re: Help needed on peculiar use of cryptography (John Savard)
Re: A question about odd grilles (John Savard)
Re: Help needed on peculiar use of cryptography (John Savard)
Re: Block chaining ("Douglas A. Gwyn")
Re: Mac encryption algorithm? ("Douglas A. Gwyn")
Re: NIST, AES at RSA conference ("Douglas A. Gwyn")
Re: NIST, AES at RSA conference ("Douglas A. Gwyn")
Re: NIST, AES at RSA conference ("Douglas A. Gwyn")
Re: Is there a practical guide to using crypto? ("Douglas A. Gwyn")
Re: How to password protect files on distribution CD (Dave Mundt)
----------------------------------------------------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: ascii to binary
Date: Sat, 29 Jan 2000 15:06:36 -0500
int i,x;
char str[] = "blah blah blah";
for (i = 0; i < strlen(str); i++) {
printf("%c = ", str[i]);
for (x = 7; x >= 0; x--) {
if (str[i] & (1<<x))
printf("1");
else
printf("0");
}
printf("\n");
}
Bitwise operations are what you need to learn about.
- Adam Durana
"Chris Engstrom" <[EMAIL PROTECTED]> wrote in message
news:TXGk4.13$[EMAIL PROTECTED]...
> I am having difficulty converting (visually) ascii to binary.
>
> for learning purposes, i want to take some text and print it out in
binary.
> What i will then do is manipulate the text and compare the binary
> differences. I have been trying to do this in C with no luck.
>
> I was wondering if anyone could point me in the right direction?
>
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: Mac encryption algorithm?
Date: 29 Jan 2000 18:11:47 -0700
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 except the top of
the iceberg of continually takikng the width of numbers into account?
>> 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. How often does that happen in non-buggy code?
>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 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?
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?
Do you know that C and relatives call by value, 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?
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.")
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Is there a practical guide to using crypto?
Date: Sun, 30 Jan 2000 01:04:04 GMT
On Sat, 29 Jan 2000 10:35:31 -0700, "JCardinal"
<[EMAIL PROTECTED]> wrote, in part:
>Is there a tutorial or faq someone could point me to that explains the
>practicalities of using encryption? There are a million deeply
>technical/mathematical articles and I have seen them all in the last few
>days, but I can't seem to find a practical one.
A lot of what Bruce Schneier has written is practical, even though he
has also got some of that heavy technical stuff at the Counterpane
site. His famous book, Applied Cryptography, is aimed at computer
professionals who don't necessarily know much about encryption, and it
gives them conservative advice.
My own web site tries to keep math at a minimum, but although there
are some sections on practicalities, it's mostly focussed on cipher
design by giving historical examples.
>One thing I really want to know is if I use a 128bit key and encrypt a file
>using twofish in ecb mode, whats to stop someone from attempting every
>possible 128bit key until they decrypt it?
>It seems like it would be a trivial matter if the person knew what
>encryption algorithm was used. I know I'm missing something fundamental
>because it's not supposed to be that easy, and thats why I dont want to use
>it until I understand it a little better.
This question I can answer. It _is_ trivial - in the theoretical,
mathematical sense. But every possible combination of 1 and 0 within
128 bits means an awful lot of combinations to try. 10 bits allow 2^10
values to be represented - there are 1,024 different combinations. So
128 bits allow over
250,000,000,000,000,000,000,000,000,000,000,000,000
possibilities (250 for 256, from those extra 8 bits, multiplied by
1,000 twelve times).
Even with today's fast computers, that's just too many to bother
trying.
However, DES was cracked - with a $250,000 computer set-up, in a
matter of days. But it had only 56-bit keys, which allow over
60,000,000,000,000,000
possibilities. Now, that's an awfully big number too, but that 128-bit
key is over
4,000,000,000,000,000,000,000
times harder to brute-force search. (In other words, really big
numbers multiply and divide just like the small ones - as I'm sure you
know, but people sometimes are so awed by any big number that they
forget that momentarily.)
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Help needed on peculiar use of cryptography
Date: Sun, 30 Jan 2000 00:54:28 GMT
On 29 Jan 2000 12:56:58 -0800, [EMAIL PROTECTED]
(David Wagner) wrote, in part:
>I'm not sure even large-scale disclosure is guaranteed to be prevented.
It isn't. Buy one copy of the program legitimately, and to crack the
system wide open, all you need is to disassemble a program, not do any
cryptanalysis at all.
Note, though, that the *activation key*, not the serial number, would
match the decryption key in size, and the activation key can be made
longer than a serial number; as long as, say, 20 mixed alphanumerics.
Which is just over 100 bits. So the objection concerning the size of a
serial number is not the problem, I think.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NEC claims New Strongest Crypto Algor
Date: Sun, 30 Jan 2000 01:23:17 GMT
"SCOTT19U.ZIP_GUY" wrote:
> It would be quite possible to any one who exaimed my contest that in method
> such as scott19u can have many fake keys. That is you encrypt your message
> with the secret key of your choice. And than you create a false key be taking
> some safe message and generating a key that would casue the fake message
> to be mapped to the same cipher text. This is quite easy when one has over
> a million bytes of key space for most messages. You could then leave the fake
> key around for someone on a fishing expedition to find and they would think
> they discovered something hot. But this whole approach relies on one useing
> decent encryption. The short keyed AES methods that the NSA wants fools to
> use would never have keys long enough to do this kind of real encryption.
The only way this can work is for the key to have size comparable to
the message. Thus it suffers from the standard one-time pad key
distribution problem. Most practical applications of cryptology
require that the key be much smaller than the protected data.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Q: DFT
Date: Sun, 30 Jan 2000 01:26:02 GMT
Mok-Kong Shen wrote:
> DFT, like all such transforms, has an inverse. However, due to the
> unavoidable rounding errors of real computations involved, a vector
> of integers might not get back to exactly the same values. What
> techniques can one best employ to obtain an exact inverse?
Most cryptologic applications of DFT of which I am aware use a
DFT over a finite field, which is an exact operation with an
exact inverse.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: A question about odd grilles
Date: Sun, 30 Jan 2000 01:06:49 GMT
On Sat, 29 Jan 2000 15:35:33 -0600, [EMAIL PROTECTED] (wtshaw) wrote,
in part:
>Considering that a grill with an odd number of characters has a character
>directly in a matrix, is there a traditional way to handle it.
I think there is. An old book - sometime in the 1920s - published by
Popular Science magazine showed all sorts of scientific wonders of the
age. There was a page about a "cipher expert" using a captured German
grille on an intercepted message. The hole in the center was open, but
it had a black border around it, and the instruction was to use it
only when the grille was in the first position.
All this is on my site, in the section entitled "Methods of
transposition" in the first chapter on paper-and-pencil methods.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Anyone read this book?
Date: Sun, 30 Jan 2000 01:10:26 GMT
On Sat, 29 Jan 2000 17:51:28 GMT, [EMAIL PROTECTED]
(Paris Guffey) wrote, in part:
>but does it do a good job about
>cryptanalysis?
For that, I think you would need another book. But it is reasonably
priced, and is a reasonably good reference for what it does cover.
For cryptanalysis, there is the book, still available from Dover, by
Helen Fouche Gaines, Cryptanalysis (originally titled Elementary
Cryptanalysis) - but that deals with paper-and-pencil systems
exclusively, however it is an excellent introduction. There is the
more recent book from Springer-Verlag, Decrypted Secrets, by Bauer,
which covers a number of areas.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Help needed on peculiar use of cryptography
Date: Sun, 30 Jan 2000 01:13:31 GMT
On Sat, 29 Jan 2000 18:36:02 GMT, [EMAIL PROTECTED] (David P Jablon)
wrote, in part:
>John, don't fool yourself. Given the small space of SS #s, a
>brute-force search will reveal which # matches the hash very quickly.
You're right. (My reply to the next poster was based on confusing this
with another thread, about protecting CD-ROM software.) But salt might
obscure the "informational value" if they do want to cross-match
between their files, as long as the number doesn't get out. Also,
apparently the data is already being kept secure - the company is
observing its nondisclosure agreements, so cryptography is claimed as
being needed primarily to reassure clients.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: A question about odd grilles
Date: Sun, 30 Jan 2000 01:17:38 GMT
On Sun, 30 Jan 2000 00:51:24 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>Isn't it that for a turning grille the holes cut can't be entirely
>arbitrary, for otherwise some of the holes at the four positions
>could possibly overlap? What are the general rules for cutting
>the holes?
Yes, there is a general rule. (See "Methods of Transposition", on my
site.) Essentially, you divide the grille into quarters, and number
each quarter the same way after it is rotated into the top position.
Then you cut only one of the four holes corresponding to each number
used.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Help needed on peculiar use of cryptography
Date: Sun, 30 Jan 2000 01:14:19 GMT
On Sun, 30 Jan 2000 00:54:28 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>Note, though, that the *activation key*, not the serial number, would
>match the decryption key in size, and the activation key can be made
>longer than a serial number; as long as, say, 20 mixed alphanumerics.
Oops. Wrong thread.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Block chaining
Date: Sun, 30 Jan 2000 01:30:55 GMT
zapzing wrote:
> You know I , personally, have
> always wondered why people bother to do
> block chaining at all. If you had a
> good block size, say 256 bits, you
> could make half the block be random
> numbers and half be plaintext.
> Then no chaining would be necessary,
> and an error in one block would not
> propagate through the whole
> subsequent message. Also you could
> use parallel processing to encrypt
> the message, something to think
> about for the future.
Chaining modes aren't intended for error recovery,
although many of them do provide a measure of that
as a side effect. The main purpose of chaining is
to thwart verious cryptanalytic attacks. If every
block is encrypted with exactly the same key, some
attacks can exploit that.
Also, padding to such an extent with random data
is a waste of bandwidth.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Mac encryption algorithm?
Date: Sun, 30 Jan 2000 01:33:52 GMT
Vernon Schryver wrote:
> In article <[EMAIL PROTECTED]>,
> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> >It's pretty evident to people who've dealt extensively with both,
> >that little-endian is "more natural" from the point of view of
> >arithmetic and addressing. For example, consider how it supported
> >pass-by-reference integers in DEC PDP-11 FORTRAN; that was so
> >important that the implementation of 32-bit integers did not
> >match the mixed-endian storage layout of the FP-11 floating-point
> >unit (which included support for 32-bit integers), despite the
> >speed advantage had the FP-11 layout been used. With big-endian
> >representation, the low-level operations constantly have to take
> >word size into account; little-endian representation is much more
> >cleanly extensible.
> That is a religious view without factual basis.
To the contrary, as I explained, a deliberate decision was made
to not use the native hardware support for 32-bit integers, due
entirely to the practical advantage of the little-endian
representation. Which we actually exploited, frequently.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sun, 30 Jan 2000 01:36:33 GMT
John Savard wrote:
> However, if "we can't get proof" is also considered as a reason to,
> failing some way to obtain proof, try to at least do everything we can
> to make our ciphers stronger - without proof that we have done enough,
> without the knowledge whether or not we may have done more than is
> necessary - then things like Mr. Ritter's multi-ciphering are entirely
> sensible responses to the situation.
But then you need proof that such methods actually *do* "make
our ciphers stronger". Adding complexity doesn't always help,
as witness Knuth's super-random number generator example.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sun, 30 Jan 2000 01:47:21 GMT
John Savard wrote:
> If there were a solution to the Halting Problem, then there would be
> no unsolved problems in mathematics - as Fermat's Last Theorem (or
> course, now solved) and the Goldbach Conjecture, for example, could be
> phrased in the form of a program.
How? You have really overstated the applications.
> Being able to say that a given cipher can't be broken requires one to
> know all the ways that a cipher could possibly be attacked, ...
No, in fact that is a fruitless approach.
Obviously, every keyed cipher can be broken, by guessing the key.
An actual *practical* proof of secrecy must be couched in terms of
probabilities (or equivalent notions such as information or entropy),
e.g. that a randomly chosen PT would be recovered by >any< fixed
attack algorithm analyzing CT only, with likelihood 10^-32 after
performing 10^80 basic operations using 10^64 bits of storage.
The hard part is proving something of the sort for >any< fixed
attack, as you cannot just loop through each possible attack.
Whole *classes* of attack must be dealt with in any such analysis.
In fact that is where the power of abstract mathematics would be
most useful.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sun, 30 Jan 2000 01:49:05 GMT
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.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Is there a practical guide to using crypto?
Date: Sun, 30 Jan 2000 02:04:26 GMT
JCardinal wrote:
> However I dont' really know anything about it in terms of:
> how do you use it in a manner that ensures your not exposing
> any weaknesses.
That's the big question, to which there is no simple answer.
Almost *all* implementations of cryptosystems have weaknesses,
especially on non-secure systems like a typical PC.
> One thing I really want to know is if I use a 128bit key and
> encrypt a file > using twofish in ecb mode, whats to stop
> someone from attempting every possible 128bit key until they
> decrypt it?
Surely that must be in the sci.crypt FAQ? What you describe
is known as a "brute force" key search, and is not feasible
for 128-bit keys simply due to the amount of time it would
require for the fastest available computer to test each key.
The calculation is simple: There are 2^128 possible keys;
testing each might require, say, 2^-28 seconds on a super-fast
computer, so testing all keys would take 2^100 seconds. If
you consider the system secure enough if there is only a 2^-20
chance (one in a million) of a message being read by the
interceptor, then your system is "cracked" after 2^80 seconds
on average. 2^80 seconds is about 4x10^16 years, which is
*much* longer than the estimated age of the universe. The
bottom line is that a 128-bit key is more than sufficiently
secure against brute-force key search. Even if computers
could become a billion times faster, we're still looking at
more time than could ever be spent, not to mention the truly
astronomical cost of recovering just one key.
------------------------------
From: [EMAIL PROTECTED] (Dave Mundt)
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: How to password protect files on distribution CD
Date: Sun, 30 Jan 2000 02:07:24 GMT
Chuck <[EMAIL PROTECTED]> wrote:
*snip*
>Also, nobody has come up with a dongle-protection scheme yet that
>can't be cracked. You'll find a long list of cracks for
>"dongle-protected" programs in the crack groups. It's just a big scam
>by the sleazy copy-protection companies who claim that their schemes
>are "absolutely impervious" to cracking even though widely-known
>cracks have been around for years.
>
This is true. The fact of the matter is that NO encryption scheme
is totally impervious to attack. However, the point is, of course, to
make it simpler for the average user to bite the bullet, whine and pay
the cost of the dongle.
>This thread may have gotten off on a tangent. I don't think the
>original question was about software copy-protection so much as a way
>to password-protect general data. Since this is a commercial use, PGP
>would require payment while the GNU version would still be free. If
>we're talking strictly Windows 9x systems (not Windows 2000 or NT)
>then scramdisk might also be a good solution (see
>comp.security.scramdisk).
>
This is a reasonable point. However, the original post DOES talk
about shipping software out in encrypted form, so only a given
customer could use it. They also imply that they want to do something
like sending out a software package with many functions (say, G/L,
Inventory, payroll, etc) and control the end user's access to any
given set of function by the license number/password assigned to the
user.
Your suggested solutions are quite valid though, and, would
probably meet the needs of the user.
Frankly, it is a shame that folks WILL use software without paying
for it. I think mIRC is a good example...I understand that they have
just had their 10,000th registration...after something like 18 MILLION
downloads. Of course, this is not to say that there are 18 million
USERS of mIRC not paying for it...Shucks, I have d/l it several times,
but, don't use it (too much noise) However, I have recommended it to
a number of folks, though.
Regards
Dave Mundt
Remove the "REMOVE_THIS_" from my email address to get to me...
I hate Cullers who gather from newsgroups
Visit my home page at http://www.esper.com/xvart/index.html
------------------------------
** 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
******************************
