Cryptography-Digest Digest #865, Volume #9 Sun, 11 Jul 99 11:13:03 EDT
Contents:
Re: New Encryption Product! (humor) (wtshaw)
Re: Stream Cipher != PRNG ("Douglas A. Gwyn")
Re: New encryption methods (wtshaw)
Re: How Big is a Byte? (wtshaw)
Re: I don't trust my sysadmin (Lincoln Yeoh)
Re: Is Stenography legal? (Lincoln Yeoh)
RSA Cryptography Today FAQ (1/1) ([EMAIL PROTECTED])
Re: How Big is a Byte? (was: New Encryption Product!) (Rob Warnock)
Re: How Big is a Byte? (was: New Encryption Product!) (Harvey Taylor)
Re: Properties of Chain Addition? ([EMAIL PROTECTED])
Re: Benfords law for factoring primes? ("Keith Lockstone")
Re: Uncrackable? (James Andrews)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.security.pgp
Subject: Re: New Encryption Product! (humor)
Date: Sat, 10 Jul 1999 23:47:52 -0600
In article <p9Bh3.2065$[EMAIL PROTECTED]>, "ruiner"
<[EMAIL PROTECTED]> wrote:
> such as the Usenet messages being read right now: 7 bit
>
> > It would have been funnier if it were right. A byte need not have
> > exactly 8 bits, although that is such a common misconception that
> > it is used in labeling disk drives, etc. That's why in technical
> > work, such as Internet packet specifications, we prefer the term
> > "octet" when we mean precisely 8 bits.
>
> ruiner
> http://home.adelphia.net/~alexk
It seems that Usenet allows more than that, since the occasional character
pops up in my reader that is not in the lower part of the ascii set. And,
sometimes lots of boxes appear on my Mac as characters in the set chosen
for viewing does not have these codes assigned display values.
One problem with using 8 bit characters is that the upper ones are in not
universal, with possible exceptions(?).
--
Rest sometimes allows you to find new things to worry about but should give you the
patience to do something about them.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Stream Cipher != PRNG
Date: Sun, 11 Jul 1999 05:57:34 GMT
[EMAIL PROTECTED] wrote:
> ... Yes, stream ciphers generally *are* built with PRNGs.
No, they are not.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: New encryption methods
Date: Sun, 11 Jul 1999 00:53:27 -0600
In article <2POh3.7323$[EMAIL PROTECTED]>, "User"
<[EMAIL PROTECTED]> wrote:
...
> Note that for this example, its a tradeoff between base (number of symbols
> per digit) and length (number of digits).
>
> To represent 1000000000 in base 1000000000 requires only 1 digit
> To represent 1000000000 in base 10 requires 10 digits
> To represent 1000000000 in base 2 requires 30 digits
>
> Somewhere inbetween those values is a good match for compressing
> numbers, letters, or anything (even 256 bit/color pixels)
You have hit on an important point, one that I have spoken to before, and
will again: Depending on the nature of content, it makes good sense to
have an appropriate set, which can be easily converted to selected other
bases. Some options are better than others.
Ease and speed will be a consideration for general use, but for security,
those things may not be much of a consideration.
>
> Since most encryption schemes nowadays are limited by the byte
> (represents 0-256), would it be possible to create a new encryption
> standard based on a different "base"?
When you talk of different bases, you are talking of different information
units. The classical approach was for sets that were language handy, 24,
25, etc. You have lots more usable options, even for text; base 22 on the
low side works well.
>
> And does making the "base" of the encrypted text unknown
> to the cracker make it more secure?
It can, as the new base can be hidden, either with nulls, or with a
process I call *phasing*, which allows a hand-picked decrease in set size
with a payment for the priviledge in added length to the group.
A process called *base translation* involves something more than merely
arithmatically changing characters from one base to another. Dealing with
multiple character sets allows for as many substitution and transposition
keys; algorithms may be easily written, probably not using all possible
keys.
It may be handy to go through some unusual third base to make an efficient
pass from the original base to a secondary one. If you want obscurity in
an unknown cipher type exchange, you can create lots of headaches as would
be breakers are not apt to be ready to launch an appropriate attack, but
should think about doing so.
>
> The person trying to crack it now also have to take into consideration
> what base it is in (which can be anything!!!)
If the idea is to make ciphers difficult to deal with, since the exact
descriptions might not be known, this base switching stuff is surely is
rich for doing that.
I try only to talk about algorithms that I have actually implemented, but
research into the area has allowed me to define hundreds of possible good
ones, with loads more that even I would consider questionable.
The whole subject is lots of fun to deal with, and the resultant
applications are practical examples of usable systems. I started working
with simple bases and with calculations not too difficult. I have gone
pretty far afield while looking at the plethora of options.
After writing a series of applications that converted base 100 to bases
12, 13, 14, 15, 16, 18, 22, 27, 32, 33, 36, 40, 47, 57, and 64, using
where appropriate digits, bits, hexits, the latest per request to do more
to base 64, converts base 27 to base 64 going through a doit (base 12
information unit) stage. More to come along that line, or whatever I
choose to do.
Not any change from one base to another is simple, easy, and efficient. I
try to work within parameters that I have established for qualifying
potential algorithms. There are some really weird but handy relationships
between selected bases that would escape you unless you looked for them.
--
Rest sometimes allows you to find new things to worry about but should give you the
patience to do something about them.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte?
Date: Sun, 11 Jul 1999 01:05:39 -0600
In article <7m8tu7$ras$[EMAIL PROTECTED]>, David A Molnar
<[EMAIL PROTECTED]> wrote:
> In sci.crypt Jim Gillogly <[EMAIL PROTECTED]> wrote:
> > 'bytes', which are the same size as a char." K&R defines "char" as
> > "a single byte, capable of holding one character in the local character
> > set." As Doug says, this is precisely why the term "octet" is used
> > ubiquitously in IETF for 8-bit objects. Since John brought up 360s,
>
> [snip of useful article cite and quote]
>
> > Of course, nobody disagrees that bytes are usually 8 bits on modern
> > machines, most of which (for our sins) are Intel boxes running a
> > Microsoft OS.
>
> So when Microsoft adopts Unicode as the "local character set",
> does this mean all bytes become 16 bits in length?
>
No. Remember, bloat is bad, regardless of how you justify it. Efficiency
in crypto is user oriented, and you and I just don't need to allow for the
stuctural nightmares found in some nations languages; just say no to
trying to be all things to all people as an excuse for being unable to
responsibly cater to the basic needs of any.
--
Rest sometimes allows you to find new things to worry about but should give you the
patience to do something about them.
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: I don't trust my sysadmin
Date: Sun, 11 Jul 1999 10:08:06 GMT
Reply-To: [EMAIL PROTECTED]
If your sysadmin isn't trustworthy then you're screwed. No amount of fancy
computer technology is going to fix that, unless you follow the method
below:
Securing your system from untrustworthy sysadmins.
1) Place sysadmin on ground, face down (and locked securely).
2) Install mainframe on sysadmin.
3) Loud noises from the sysadmin indicate installation progress.
4) System secured successfully when sysadmin stops breathing.
When will people realise that systems and technology are no substitute for
trustworthy people? They should spend more time, effort and money on
getting trustworthy people than on stupid systems (or finding how to
determine trustworthiness of people than computer systems). All that B and
A stuff is meaningless chasing after the wind. Wasted money, especially
when no matter what they still have to let the programmers walk in to a
"super-secure" installation to do anything.
It's silly that some people will spend plenty on the people handling their
money but be pennywise when it comes to people handling their
information/knowledge. In the Info age this is even more ridiculous.
All that technology should be used for is to _help_ the trustworthy people
not make mistakes. Prevent accidents that would cause breach of
trust/policy.
Sure "trusted people" for paranoid types is harder to pin down than
"trusted systems", but the latter are useless without the former, whereas
the former are still eminently valuable without the latter.
Cheerio,
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: Is Stenography legal?
Date: Sun, 11 Jul 1999 10:17:41 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 08 Jul 1999 17:10:12 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>Robert G. Durnal wrote:
>>
>
>> First, I think you mean STEGANOGRAPHY, not STENOGRAPHY. But it is
>> legal, and not against EAR. In fact, EAR does NOT apply to sending of coded
>> messages, but only to the dissemination of encryption software itself. And
>> steganography is not encryption.
>
>If an encryption software is coded and sent (a coded message), is this
>against EAR? Presumably yes. But how is that to be controlled?
>
>M. K. Shen
The point you seem to be having difficulty with is:
If something is made illegal, it is still illegal even if no one is
watching.
If you drive through a red light and no one[1] knows about it, it is still
illegal in most nations as far as I know.
Whether or not you may get caught/sentenced is a totally different issue
from legality.
I seem to recall we were discussing something similar to this for the
Chaffing and Winnowing thread months back.
Cheerio,
Link.
[1] Even if you don't know about it it's still illegal (maybe especially so
if you're that drunk!).
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
talk.politics.crypto,alt.security.ripem,sci.answers,talk.answers,alt.answers,news.answers
Subject: RSA Cryptography Today FAQ (1/1)
Date: 11 Jul 1999 11:32:46 GMT
Reply-To: [EMAIL PROTECTED]
Archive-name: cryptography-faq/rsa/part1
Last-modified: 1997/05/21
An old version of the RSA Labs' publication "Answers to Frequently Asked
Questions about Today's Cryptography" used to be posted here until May
1997. These postings were not sponsored or updated by RSA Labs, and
for some time we were unable to stop them. While we hope the information
in our FAQ is useful, the version that was being posted here was quite
outdated. The latest version of the FAQ is more complete and up-to-date.
Unfortunately, our FAQ is no longer available in ASCII due to its
mathematical content. Please visit our website at
http://www.rsa.com/rsalabs/ to view the new version of the FAQ with your
browser or download it in the Adobe Acrobat (.pdf) format.
RSA Labs FAQ Editor
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Rob Warnock)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: 11 Jul 1999 12:25:37 GMT
<[EMAIL PROTECTED]> wrote:
+---------------
| ...byte was something that could take between 64 and 100 values.
|
| Of course, that fellow had been reading the definition of "byte" found in
| Donald E. Knuth's description of the MIX computer, not realizing that it
| was not intended as a general definition of the term.
|
| However, AFAIK, that is the *only* place the term byte has ever been used
| to describe anything other than an (ahem) octet...
+---------------
*BZZZT!!* Wrong-O!! (How quickly they forget...) The DEC PDP-10 had
hardware support for *variable*-length bytes for any length of byte from
1 to 36 bits. PDP-10 Byte Pointers contained a memory word Address, a
byte Size, and an offset-within-the-word Position (and also an index
register and an indirection bit, but let's ignore those). The Increment
and LoaD Byte (ILDB) instruction took a Byte Pointer and adjusted the
Position subfield to designate the next sequential byte of that Size
within the word (incrementing the word Address and resetting the Position
to 36-Size, if necessary), then loaded the now-pointed-to byte (of size
Size) into the indicated accumulator register. IDPB did the equivalent
store (DePosit) function. LDB/DPB did load/store byte without incrementing,
and IPD only incremented a Byte Pointer.
The PDP-10 concept of arbitrary and variable byte sizes lives on in the
ANSI Common Lisp standard, in the functions BYTE, BYTE-SIZE, BYTE-POSITION,
LDB, and DPB. For more, see <URL:http://www.harlequin.com/education/books/
HyperSpec/Body/fun_bytecm_by_yte-position.html> where this example is given:
(setq b (byte 100 200)) => #<BYTE-SPECIFIER size 100 position 200>
(byte-size b) => 100
(byte-position b) => 200
See also:
http://www.harlequin.com/education/books/HyperSpec/Body/acc_ldb.html
http://www.harlequin.com/education/books/HyperSpec/Body/fun_dpb.html
+---------------
| the term byte was coined and defined, with a definition that made no
| provision for the term referring to any other quantity of storage...
+---------------
Again, incorrect.
+---------------
| in "System/360 Principles of Operation".
+---------------
The PDP-10 -- and the term "byte" -- *long* predated the S/360.
-Rob
=====
Rob Warnock, 8L-855 [EMAIL PROTECTED]
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
------------------------------
From: Harvey Taylor <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Sun, 11 Jul 1999 08:27:26 -0700
Dennis Ritchie wrote:
> David Eppstein wrote (after quoting and referencing):
>> Anyway, this pretty conclusively demolishes the original poster's
>> contention that Knuth is the only source to refer to something other
>> than an octet as a "byte".
>[references elided]
> "Byte" denotes a group of bits used to encode a character, or
> the number of bits transmitted in parallel to and from input-
> output units. A term other than 'character' is used here
> because a given character may be represented in different
> applications by more than one code, and different codes
> may use different numbers of bits (i.e. different byte sizes.)
> .... (The term is coined from 'bite', but respelled to avoid
> accidental mutation to 'bit.')"
>
I remember when I first ran into the sequence bit, nibble, byte
thinking that it would have been neat if 'word' was edible, so
to speak.
I don't hear anyone wondering about the real size of a word,
but I sure see it in code; windoze, vxworks...
BTW, does anyone know where the term nibble arose?
>[...]
<curious>
-het
--
"The earth is the cradle of mankind, but we cannot stay
in the cradle forever." -Konstantin Tsiolkovsky
Harvey Taylor [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: Re: Properties of Chain Addition?
Date: Sun, 11 Jul 1999 13:10:23 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] () wrote:
> Well, I remember you mentioned that you had C code for such
generators,
> but I wasn't looking for that; I was looking for math references that
> would tell me stuff about the period and so on.
Well the period is exactly
(2^r - 1)(2^(w-1)), r = length in elements, w = word size in bits.
There are 2^((k-1)(m-1)) different full length cycles (acording to [1]).
That is for additive generators. For multiplicative generators they
have a period of
(2^r - 1)(2^(w - 3))
But perform slightly better on stats tests.
Any LFSR polynomial with two taps should work. I haven't seen any good
theory on the net though...
> The requirement, no doubt, is simply that the feedback arrangement be
a
> primitive polynomial mod n, but I was hoping that the polynomial
x^n+x+1
> might be a special case that is particularly likely to be primitive.
Well (7, 1, 0) and (4, 1, 0) are in that configuration and are maximal
period. I use (55, 24, 0) and (52, 19, 0) which are from FISH since
they are both relatively prime (i.e when combined are max period) and
perform quite well on stats tests (i.e distribution and independance)
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] ("Keith Lockstone")
Subject: Re: Benfords law for factoring primes?
Date: Sun, 11 Jul 1999 14:12:32 GMT
I wondered how long before that New Scientist article would rattle a few
cages....
In article <CiRh3.12404$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Blank) wrote:
> Has anyone looked into using Benfords ( prob first digit D = log 1+1/D
> ) law
> to sort the lists of potential factors for brute force prime cracking?
> Do
> observable primes obey Benfords law. Its late here and my quickly hacked
> little VB pgm seems to say no.
>
> I
>
>
>
>
>
------------------------------
From: James Andrews <[EMAIL PROTECTED]>
Subject: Re: Uncrackable?
Date: Sun, 11 Jul 1999 14:46:27 +0100
Reply-To: [EMAIL PROTECTED]
Ok, I'll supply the sources, but first I'll describe what I believe constitutes
the reliability of this method. The method works using a single 4 -> 12 letter
password, rather than a pseudo-randomly generated key of arbitrary length. It is
a one key, reversible process so its admittedly not ideal for public mailing etc,
but for password encryption or data hiding, or even remote access to a machine to
which you have local access (for which purpose I've written a simple protocol
which also eliminates the need to send the password over the network, so access
through monitoring packets would be virtually impossible. I'll post later if
anyone is interested?). After reading through the source of the standard unix
crypt() commands DES encoding, I sat down and thought for a while and decided that
surely enxryption doesnt need to be that complex in order to be infinitely
difficult to reverse. My conclusion was that it could be made *almost*
irreverible if at every possible stage you diffuse the information so that the
possible paths back to the original content/key are far too numerous to
comprehend. This is how I tried to solve this.
This method of encryption (I've named it CM26, dont ask but I have my reasons)
takes a password between of between 4 and 12 characters. The bytes used for these
passwords are then used to seed
up to 3 random number generators. Each random number generator then generates one
long integers which are broken down into bytes. Each byte of the source file is
then diffused in turn with each generators output. The first using an XOR, the
second if present using an ADD, the third if present using another XOR. This
method can then be reversed simply by getting the same seeds from the password,
generating the same streams, and XOR'ing with the 3rd, SUB'ing the 2nd and XOR'ing
with the 1st stream.
The data which comes out has been suitably mashed with a significant amount of
pseudo random numbers. But since each process has both scope and resolution of
the full byte for both inputs (the random number and the data) the number of
potential combinations that would be required even to find the reverse random
streams, let alone finding the seeds which generated them, are unfathomable. My
thoughts were, firstly, it would take a ludicrous amount of time to find all the
possible seeds, and secondly, you can never be sure whether the method you found
was the right one. There may well be ghost seeds which also claim to fit the
bill, but actually just corrupt the data more.
For the source in java of the alpha version of this algorithm, see:
http://vote3.sgbs.strath.ac.uk:8765/james/CM26.html
I have a few further things I'd like to do with this algorithm, and I know before
I start getting hundreds of posts, there are a few minor details like not having
the full 2^96 range of possibilies due to alpha-numeric passwords not using the
full unsigned byte range, but the sheer volume of possibility coupled with the
fact that there is no clear marker that any given password works unless you know
what you are looking for makes it seem, at least to me, like a very secure
algorithm.
It works in java because all java distributions use the same random number
algorithms. I'm thinking of moving it over to use ISAAC since that would mean
that the first 2^40 bytes of the file would be generated in a completely unique
fashion. As it stands, with the 3 streams working on the file there doesnt appear
to be any noticable periods, cycles or direct correlations between either the
source and encrypted, or two encrypted files using the same password/key.
Well, judgement time, as I said before, I dont claim to be any kind of expert on
cryptology, but from my experience as a programmer, theoretically and logically,
this seems to be an immensly secure system. If anyone finds any flaws in it,
please let me know rather than just flame me. I wrote this out of pure interest,
and I want to know what you think, thanks,
James
------------------------------
** 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
******************************
