Cryptography-Digest Digest #651, Volume #12 Mon, 11 Sep 00 00:13:01 EDT
Contents:
Re: RC5-SAFE? - SAFEBOOT ("Paul Pires")
Re: Encrypted internet voice solutions ?? (Paul Rubin)
Re: RSA public exponent (Bill Unruh)
Re: CRC's as MAC's (David A. Wagner)
Re: RSA public exponent (Future Beacon)
Re: RSA public exponent (Ed Pugh)
Re: RC5-SAFE? - SAFEBOOT (Tom St Denis)
Re: Scottu19 Broken (SCOTT19U.ZIP_GUY)
Getting Started, advice needed (FAQs , yes I read them) (Andy C)
Re: RSA public exponent (Rich Wales)
Steganography and secret sorting (Matthew Skala)
Re: Bytes, octets, chars, and characters ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: RC5-SAFE? - SAFEBOOT
Date: Sun, 10 Sep 2000 17:07:00 -0700
lala <[EMAIL PROTECTED]> wrote in message
news:8ph74o$t63$[EMAIL PROTECTED]...
> I didn't want start a flame war. But thanks both for advice. P.S. Tom when
> you say 'I would avoid the program at all costs.' - is this because it is
> trully insecure or too slow? I'm not trying to defeat the NSA here only
> ensure data is inaccessable from mid/large business for a year or two.
My apologies for hijacking your question. Hope you got what you need
If not, follow up. My spleen is well vented and I promise not to nag :-)
If I could guess at what Tom means, it would be that there are other well
regarded solutions out there that perform better. Kent Brigg's website seems
to be one good place to look. Just a guess, You didn't go into a lot of detail
about what your constraints, needs and preferences are.
If I have miss-guessed him, I'm sure he'll gently correct me :-)
Paul
>
>
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:8pftps$7th$[EMAIL PROTECTED]...
> > In article <1gDu5.37341$[EMAIL PROTECTED]>,
> > "Paul Pires" <[EMAIL PROTECTED]> wrote:
> > >
> > > Tom St Denis <[EMAIL PROTECTED]> wrote in message
> > > news:8pesut$5sf$[EMAIL PROTECTED]...
> > > > In article <8peohu$2n8$[EMAIL PROTECTED]>,
> > > > "lala" <[EMAIL PROTECTED]> wrote:
> > > > > Sorry, I', a novice, so sorry if this question is stupid. I
> > believe
> > > > this
> > > > > program is great for total disk encryption.
> > > > > Some information sent to me says,....
> > > > > "The encryption method is based on the RC5 algorithm published by
> > RSA
> > > > > Laboratories. This algorithm uses a 1024 bit key and 12 rounds
> > with a
> > > > 32-bit
> > > > > word size in CBC mode. Using this method, SafeBoot is able to
> > encrypt
> > > > data
> > > > > at the rate of ~6MB/sec."
> > > > > Is this totally insecure, or still not bad encryption? It's the
> > 32bit
> > > > not
> > > > > the 1024 bit I should be looking at right? i.e. this is not 128bit
> > > > > encryption. Thanks for advice.
> > > >
> > > > Your obviously a crypto-newbie. The 32-bit word size means RC5 is
> > > > implemented as a 64-bit block cipher. The 1024-bit key is a bit
> > > > disconcerning since RC5 is normally only used with keys from 64 to
> > 256
> > > > bits. 1024 bits seems excessive.
> > > >
> > > > Also with 12 rounds a differential or linear attack could in theory
> > be
> > > > applied, I would use at least 16 rounds and hope not to have a weak
> > key
> > > > (low chance really).
> > > >
> > > > plus 6mb/sec is really slow. My RC5 code with 12 rounds gets 22.25
> > > > MB/sec on my K6-2. So thats about four times slower then it should
> > be.
> > >
> > > Sorry for the off track but...
> > >
> > > It's Dennis Miller time.
> > >
> > > Gosh, if everybody would state the platform and clock speed when
> > > discussing stats it would be so nice. Clocks per byte isn't great but
> > I think
> > > it's the most relevent spec if it is derived from actual testing.
> > Another wonder
> > > spec is when someone posts C source and then claims performance for
> > > what is obviously a higly optimized, pipelined nitro-burning
> > assembler version.
> > > "The Source is free and un-patented. Oh, you want the fast one? I'll
> > have our
> > > sales rep set up an appointment." By the way Tom. I'm not aiming this
> > at you.
> > > Your post just reminded me of it.
> >
> > Well ok, I get 15 cycles/byte with my implementation in Assembler. And
> > it's *FREE* to use if you don't live in the states. Except my RC5 key
> > schedule doesn't work right in asm (the rest is ok).
> >
> > Or you could try TC6a which is the fastest block cipher in the world in
> > plain C code on a x86 series cpu. I get 12 cycles/byte. It's rather
> > secure except for a impossible differential attack that would require
> > about 2^64 work anyways.
> >
> > Tom
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
>
------------------------------
Crossposted-To:
comp.security.pgp.tech,comp.security.pgp.resources,comp.security.pgp.discuss,alt.security.pgp
Subject: Re: Encrypted internet voice solutions ??
From: Paul Rubin <[EMAIL PROTECTED]>
Date: 10 Sep 2000 17:32:50 -0700
[EMAIL PROTECTED] (Ed Pugh) writes:
> 5. PGPfone suggests turning off error correction on the modem.
> Is this true for internet connections over a PPP dial-up
> service as well as direct modem-to-modem connections? If
> so, should this also be done for the other programs
> (Nautilus, SpeakFreely)?
Yes, at least for modem-to-modem connections. The idea here is that
it's better to take an occasional dropout in the voice stream than
increased latency going through the modem's error correction. On the
other hand, at the time these programs were written, turning off v.42
error correction also turned off stop bit deletion, so you lost 20% of
your modem's speed. Nowadays, if your modem supports v.80, that
problem is fixed.
For IP connections, Nautilus uses UDP to move the voice packets, so
benefits in the same way. I don't know about the other programs. If
they use TCP, then you're probably better off leaving v.42 turned on,
so recovery from a line hit will happen at a lower level (and
hopefully faster) than a TCP retry.
-- Paul (cryptography implementer for Nautilus)
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: RSA public exponent
Date: 11 Sep 2000 01:26:23 GMT
In <[EMAIL PROTECTED]> Future Beacon
<[EMAIL PROTECTED]> writes:
]Is the nature of the message at all relevant to finding the private
]key or is that process completely independent of the data being
]sent? Would you expect no greater difficulty in finding the private
]key if the messages were all random numbers? Is there anyway to use
]regularities known to be present in the intended message to crack
]the code?
Not sure what you are asking. The private exponent depends on on e, p
and q, and not on the messages. It is calculated well ahead of time of
any messages being sent or received and is the same for all messages
sent with that public key.
If you are asking if some attacker discovering the key may depend on the
message being sent, then yes it may. For example, if the message is
less than N^(1/e) then it is trivial to reverse (though not to find the
private key). If the same key is used to encrypt a number of messages of
a certain type and e is small then apparently there is a way of breaking
the key. So, yes, the messages can be important in breaking the key.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: CRC's as MAC's
Date: 10 Sep 2000 18:42:09 -0700
Dido Sevilla <[EMAIL PROTECTED]> wrote:
> The best idea I've been able to find so far is the use of a CRC
> algorithm. The MAC would essentially be a 128-bit CRC, encrypted with a
> block cipher, which provides our keying.
Look at the literature on 2-universal hashing & message authentication.
One provably secure construction is roughly similar to what you suggested;
but the CRC polynomial must be secretly and uniformly chosen from the set
of primitive polynomials, and there are a few other technical conditions
you must be sure to get right.
If the CRC polynomial is not secret, or not randomly chosen, then your
suggestion is definitely not secure.
------------------------------
From: Future Beacon <[EMAIL PROTECTED]>
Subject: Re: RSA public exponent
Date: Sun, 10 Sep 2000 21:43:22 -0400
Bill,
Thank you for this reply. I think you have answered my question,
but let me see if you agree with my conclusion: If the messages
themselves are nothing but random numbers, the the wiretapper or
opponent would not be able to determine what those numbers were
in many cases where a plain text messages could be deciphered.
Do you agree?
Thank you for your help.
Jim Trek
Future Beacon Technology
http://eznet.net/~progress
[EMAIL PROTECTED]
On 11 Sep 2000, Bill Unruh wrote:
> In <[EMAIL PROTECTED]> Future Beacon
><[EMAIL PROTECTED]> writes:
>
> ]Is the nature of the message at all relevant to finding the private
> ]key or is that process completely independent of the data being
> ]sent? Would you expect no greater difficulty in finding the private
> ]key if the messages were all random numbers? Is there anyway to use
> ]regularities known to be present in the intended message to crack
> ]the code?
>
> Not sure what you are asking. The private exponent depends on on e, p
> and q, and not on the messages. It is calculated well ahead of time of
> any messages being sent or received and is the same for all messages
> sent with that public key.
>
> If you are asking if some attacker discovering the key may depend on the
> message being sent, then yes it may. For example, if the message is
> less than N^(1/e) then it is trivial to reverse (though not to find the
> private key). If the same key is used to encrypt a number of messages of
> a certain type and e is small then apparently there is a way of breaking
> the key. So, yes, the messages can be important in breaking the key.
>
------------------------------
From: [EMAIL PROTECTED] (Ed Pugh)
Subject: Re: RSA public exponent
Date: 11 Sep 2000 01:53:36 GMT
Reply-To: [EMAIL PROTECTED] (Ed Pugh)
Bill Unruh ([EMAIL PROTECTED]) wrote:
> If the same key is used to encrypt a number of messages of
> a certain type and e is small then apparently there is a way of breaking
> the key. So, yes, the messages can be important in breaking the key.
Do I understand this correctly? This means that an RSA secret exponent
can be determined by an attacker if "e is small" ? If so, this is news
to me.
How small is "small" ?
Some older versions of PGP I think used 17 as a default value for e.
So if I understand you, bill, then these keys can be broken by encrypting
"a number of messages of certain type". Is there a specific method for
doing this?
Am I correctly interpreting your post, or am I misunderstanding something?
Thanks and regards,
--
Ed Pugh, <[EMAIL PROTECTED]>
Richmond, Ontario, Canada (near Ottawa)
"Bum gall unwaith-hynny oedd, llefain pan ym ganed."
(I was wise once, when I was born I cried - Welsh proverb)
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RC5-SAFE? - SAFEBOOT
Date: Mon, 11 Sep 2000 02:28:31 GMT
In article <xrVu5.55389$[EMAIL PROTECTED]>,
"Paul Pires" <[EMAIL PROTECTED]> wrote:
>
> lala <[EMAIL PROTECTED]> wrote in message
> news:8ph74o$t63$[EMAIL PROTECTED]...
> > I didn't want start a flame war. But thanks both for advice. P.S.
Tom when
> > you say 'I would avoid the program at all costs.' - is this because
it is
> > trully insecure or too slow? I'm not trying to defeat the NSA here
only
> > ensure data is inaccessable from mid/large business for a year or
two.
>
> My apologies for hijacking your question. Hope you got what you need
> If not, follow up. My spleen is well vented and I promise not to
nag :-)
>
> If I could guess at what Tom means, it would be that there are other
well
> regarded solutions out there that perform better. Kent Brigg's
website seems
> to be one good place to look. Just a guess, You didn't go into a lot
of detail
> about what your constraints, needs and preferences are.
>
> If I have miss-guessed him, I'm sure he'll gently correct me :-)
>
> Paul
You guessed wrong, but that's quite alright.
My problem is that it says a 1024-bit key and only uses 12 rounds.
Personally anything under 16 rounds is not a good idea, and you can't
use 1024-bit keys with RC5, well you could, but I wouldn't.
It doesn't seem like a well thought out use of RC5.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Scottu19 Broken
Date: 11 Sep 2000 02:34:39 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>On Sun, 10 Sep 2000 10:52:42 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote, in
>part:
>>[EMAIL PROTECTED] wrote:
>
>>: I heard that the NSA broke Scottu19, is that true?
>
>>Is http://www.deja.com/threadmsg_ct.xp?AN=666637659 the source of your
>>information? The only other mention recently here appears to be
>>http://x60.deja.com/threadmsg_ct.xp?AN=666850697.1
>
>You mean he didn't just make that up? (Although those posts hardly
>supply any real evidence, so I think I can stand behind my assumption
>that he was just joking.)
>
>Looking up the thread, I see I missed a post by David A. Scott. I will
>have to admit to him since, except for a BASIC-language version of
>Quadibloc S to generate some test vectors, I haven't implemented any
>of my designs, there probably _are_ more people using his ciphers than
>mine.
>
>While being polite and careful in what one says is helpful in being
>taken seriously, I freely admit that making the effort of writing code
>to make things easy for other people is important too.
>
>This in no way negates the _original_ intent behind the first
>Quadibloc cipher - to show that it is possible, at the cost of some
>loss of efficiency, to design a block cipher so that it is much easier
>to write a program to implement it than to write one implementing DES,
>and therefore that the description of a block cipher is almost as
>"dangerous" as code implementing it, and therefore that the
>previously-existing export restrictions faced by U.S. residents and
>citizens were not, at least for some purposes, as big a deal as
>claimed.
>
>Also, there are plenty of implementations of block ciphers out there,
>but I think my web site is worth my efforts, even if there are also
>other cryptography web sites out there.
>
>And, of course, Mr. Scott is welcome to come up with a cryptanalysis
>of Quadibloc VIII if he wishes.
>
Jhon I would not look at it till you have running code. However
I do belive the NSA is tasked to look at all ciphers. If for no other
reason they to try to gather parameters. So that when they come against
something that they are trying to break they can at least attempt to
see if it fits in with the parameters of any previous known system.
I hope mine is very hard for them to get many parameters. I am sure
they at least have looked at me code. I have seen trails left in the
log file and one time wrote back to a NSA stie that visited me.
However they gave no real response as to weather or not they looked
at it.
I think I am more of a threat to the NSA's job if people wake up
about how bad compression can leave them vulnerable to code breakers.
If people get a lttle brighter in that area and use good 1-1 compression
then the NSA job would have a much harder job of code breaking.
But what people seem to use allows for only one possible key to
decrypt most messages. And if they have or when they get good quantum
computers this will make mincemeat out of most crypto systems in
common use. But the so called crypto gods don' see it in there black
hearts to let anyone know about such concerns.
David Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
Subject: Getting Started, advice needed (FAQs , yes I read them)
From: [EMAIL PROTECTED] (Andy C)
Date: Mon, 11 Sep 2000 03:08:25 GMT
OK, I've skimmed the FAQ, read a few messages and here I am...
A friend of mine brought me this algorithm that some software he uses has
embedded in it. He reverse engineered it from the ASM code, and this is what
he found (He did it in C since he's more familiar with that idiom than ASM):
(ints 32 bit intel)
void decode
(
unsigned int *mainData,
unsigned int *tempData,
unsigned int dataLen,
unsigned int theKey
)
{
unsigned int tempKey;
unsigned int temp1;
unsigned int tempLen;
int counter;
tempKey = theKey;
tempLen = (dataLen >>2);
if (tempLen > 0)
{
for (counter = 0; counter < tempLen; counter++)
{
/* */
temp1 = data[counter] + tempKey;
temp1 = ((temp1 << 19) | (temp1 >>13)) - 26087;
temp1 = ((temp1 << 23) | (temp1 >> 9));
tempData[counter] = temp1;
tempKey = tempKey + temp1 - 26087;
}
}
temp1 = data[0];
data[0] = data[tempLen << 1];
data[tempLen << 1] = temp1;
}
Ok, now for the question - is this secure enough? Thats what I want to try
to find out on my own. I've read the cryptanalysis stuff from the web, and
its more along the lines of discovering the algorithm. Well, I already have
that, so I can produce keys, known plaintexts, etc. What Im wondering is how
to go about attacking an algorithm. Its symmetric apparently, but it changes
the key every time through the loop. Is the one above a known algorithm? If
so, whats its name? If now, whats the best way to attack this? I know the
key lenght is short and it can be brute forced rather quickly (1 hour or so)
on a home PC. But I'd like to see if it can be done in near real-time.
I'm wondering about the "magic numbers" this appears to have in the << and >>
and addition areas. Is that the proper place to start looking? And if so,
what am I looking for?
Thanks for putting up with a first time poster.
------------------------------
From: [EMAIL PROTECTED] (Rich Wales)
Subject: Re: RSA public exponent
Date: 11 Sep 2000 03:10:49 -0000
Ed Pugh wrote:
> Do I understand this correctly? This means that an RSA
> secret exponent can be determined by an attacker if "e
> is small" ? If so, this is news to me.
My understanding of this attack is that if someone encrypts the same
message "e" times, with "e" different RSA public keys, each of which
uses the same public exponent "e", then it's possible to determine
the original message without knowing any of the secret keys involved.
This attack does =not= allow you to discover an unknown secret key.
And it doesn't have any practical application to PGP, because (as I
understand it) PGP always sticks some random data at the beginning
of anything that is going to be encrypted with RSA, precisely to get
around this weakness in the system.
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED.
RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Steganography and secret sorting
Date: 10 Sep 2000 20:44:24 -0700
Suppose you've got a file full of distinct records that don't have any
particularly significant way of ordering them. As one example, some of
the data files I'm dealing with for school right now are lists of
combinatorial objects (in this case, graph embeddings) that don't have any
really natural order: the interesting question is whether or not a given
record is in the file at all, not where in the file it happens to be
located. But when you store the file on a disk, you have to put the
records in *some* order. A "standard" or "canonical" way of doing it
would be to treat the records as binary or text strings and sort them
lexicographically on that basis. But why bother sorting them at all?
Why not just store them in whatever order they happen to be generated?
Most of my files of such things are in apparently-random order.
Well... since there are lots of ways to store the same data, I can use my
selection of one of those ways to store some extra data. This could maybe
be used as an elegant trick for packing software into a very limited
system, but I'm thinking of it more as an opportunity for steganography.
If challenged, I can claim that the files are in random order just because
that's convenient. My data files are generated by computationally
intensive algorithms, and I routinely tweak the algorithms in ways that
completely rearrange the order of output. The order of output may not
even be deterministic when I split file generation into multiple parallel
processes on multiple machines and feed the results all back into the same
file, as I sometimes do. So anyone without the complete history of my
research (including information that even I don't store) would be
hard-pressed to prove that the ordering in a given file wasn't generated
by one of my experiments.
If there are n records in the file, there are n! ways to arrange them and
the amount of information that could be stored by choosing an order for
the records is proportional to log n!. By Sterling's approximation, I
estimate the number of bytes that can be hidden in a file as
(n+0.5)(ln(n)-1)/A + B
where
n = number of records
A = ln(256) ~= 5.545
B = (1+ln(2*pi))/2 ~= 0.256
If my records are, for instance, 65-character text lines, then I could
roughly estimate that a CD-ROM will hold 10 million of them; by the above
formula, that can hide about 27 megabytes. One of the interesting
features of this scheme is that doubling the file size (number of records)
will *more than double* its capacity (!) because it's basically an n log n
thing. Of course that's an illusion, you can't push it far enough that
the steganographic capacity becomes bigger than the actual size of the
file. It will break down when the required record count exceeds the
number of possible records allowed by the size of the records, but it's
still an amusing feature that would probably apply to many real
applications.
So to hide a message, I envision taking a large file, sorting it, and then
expressing the first few bits of the secret data as a number between 0 and
n-1 and using that number to choose one of the sorted lines to be first in
the output. Then I use the next few bits of the secret data to choose a
number between 0 and n-2 and use that to choose one of the remaining
lines, and so on. The receiver can take the file I transmit, sort it, and
recover the sequence of numbers I chose, which in turn can be converted
back to the secret data.
The simplest thing to do would be just use a regular lexicographic sort on
the lines, but for security purposes it might be a better idea to have a
secret definition of "sorting" shared between the communicating parties.
Offhand, it seems like a good thing to do would be encrypt each record and
sort the results to generate the "sorted" order for use in the algorithm.
Note that no encrypted data would actually be transmitted - the encryption
would be used only to generate the sorted order which is then further
rearranged in order to hide the secret message. I'm going to have to
think about whether the result of "encrypt each record and then sort" is
distinguishable from the result of "choose a reordering of records
uniformly at random"; that seems like an important question for the
security of that kind of "secret sorting".
Would anyone care to comment on this scheme? Do you know if anyone's
investigated schemes like this before, where a secret message is concealed
in the order of a bunch of things that don't have to be in any particular
order?
--
Matthew Skala
[EMAIL PROTECTED] I'm recording the boycott industry!
http://www.islandnet.com/~mskala/
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: Mon, 11 Sep 2000 00:06:36 -0400
Chris Rutter wrote:
> However, it now seems to be a widespread portability assumption that
> `int', and even `long', are 32 bits wide. This necessitated the
> creation of `long long': if people had stuck to the rules, a 64-bit
> `long' type would have worked without problems, as I see it.
No, the real problem is that while there were barely enough standard
integer types to fit all the power-of-two widths without duplication
if that was what the implementors wanted to do:
char 8
short 16
int 32
long 64
in fact many existing implementations intentionally made int the same
width as either short or long:
char 8
short 16
int 16 or 32
long 32
??? 64
That was done to meet the original intent that "int" would be the
generally most efficient width, while short and long were chosen to
match the way that programmers had typically been using them to pack
and unpack data structures such as IP headers. Therefore
long long 64
to accommodate that large body of existing code. In any event,
??? 128
there is no reason to think that 64 bits is as wide an integer
type as the language needs to accommodate; we already need 128
bits for an IPv6 address, for example. We made a good start at
accommodating such types in C99, so that there should be no further
disruptions as this area evolves further.
------------------------------
** 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
******************************
