Cryptography-Digest Digest #812, Volume #11 Thu, 18 May 00 12:13:01 EDT
Contents:
Re: Base Encryption: Revolutionary Cypher ([EMAIL PROTECTED])
Re: sci.crypt cipher contest (Mark Wooding)
Re: P+1 factorization algorithm (Bob Silverman)
Re: AES final comment deadline is May 15 (Volker Hetzer)
Re: P+1 factorization algorithm ([EMAIL PROTECTED])
Re: AES final comment deadline is May 15 (DJohn37050)
Re: Q: How to find good characteristics for differential cryptanalysis? (Mark
Wooding)
Re: Unbreakable encryption. ("Scott Fluhrer")
Re: random.org? (fork)
Re: NIST releases final AES comments (Mok-Kong Shen)
Interpretation of Hitachi patent claims (Mok-Kong Shen)
Re: AES final comment deadline is May 15 (Mark Wooding)
Re: Base Encryption: Revolutionary Cypher (Eric Lee Green)
Re: Base Encryption: Revolutionary Cypher (Mok-Kong Shen)
Re: random.org? ([EMAIL PROTECTED])
PADDING problems ("Karim A")
Re: Unbreakable encryption. (Eric Lee Green)
Re: Is OTP unbreakable? ("Douglas A. Gwyn")
Re: sci.crypt cipher contest (Tom St Denis)
Re: Please help to decipher (Tom St Denis)
Re: Unbreakable encryption. (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Base Encryption: Revolutionary Cypher
Date: Thu, 18 May 2000 14:09:26 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
[EMAIL PROTECTED] wrote:
> Given cyphertext:
> nphiwva8nas4xf0u8kyuw1etq3hsxb0ks4qbrlr27b6dam8tu4bily.5i
>
> Run Virtual Calc 2000
> Click on BASE button.
> Enter 36 into Custom Base Box (then press OK).
> Enter the above Cyphertext into Expressions Box (you can paste it in).
> Follow the message with +33*6/4.5
> Press Calculate.
> Click on Base Button.
> Enter 62 into Custom Base Box (then press OK).
sure it is unbreakable - because every plaintext is equally possible
(try decript with +33/4ecoleeea361.hbzzzzzzslb5ouy0dckx47vfkk59zq5)
but just like OTP you can use same key (6/4.5) only once,
if not - should be easily breakable.
and adding 33 is senseless.. it affects only last 2 characters
== <EOF> ==
Disastry http://i.am/disastry/
http://disastry.dhs.org/pgp.htm <-- PGP half-Plugin for Netscape
http://disastry.dhs.org/pegwit <-- Pegwit - simple alternative for PGP
remove .NOSPAM.NET for email reply
=====BEGIN PGP SIGNATURE=====
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
iQA/AwUBOSPdLDBaTVEuJQxkEQJ0FACdEvJmRyReEKVw/slGLPXrB/qmh9IAoKe4
/5IVFdm0KzSKCr5si/HoWdZ5
=luSS
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: sci.crypt cipher contest
Date: 18 May 2000 14:18:26 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> The server is in the states (to the best of my knowledge) so there is
> no problem sending papers to him. It's just going the other way.
>
> Personally I wouldn't worry about it.
I thought that current ruling was that source code was protected free
speech and regulating its export was unconstitutional. Or was that last
week? ;-)
-- [mdw]
Damn it, Jim: I'm a hacker, not a lawyer.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: P+1 factorization algorithm
Date: Thu, 18 May 2000 14:10:21 GMT
In article <8g0fs5$lgs$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Does anyone have source code, or a detailed description of how to
> implement, the P+1 factorization algorithm?, i.e. the one that finds a
> prime factor p of a large composite N if p+1 is smooth.
> I think I understand the theory but I don't have any experience
> of implementing an algorithm that works over GF(p^2).
>
> TIA
> Chris
The *definitive* article to read is Peter Montgomery's
Speeding the Pollard and Elliptic Curve Methods of Factorization
Mathematics of Computation, 1987
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: AES final comment deadline is May 15
Date: Thu, 18 May 2000 14:31:08 +0000
DJohn37050 wrote:
>
> I would be EXTREMELY surprised if the nationality of the submitters was a
> factor in NIST's decision. For one, there is no need and for two, if it ever
> leaked, it would be very embarrassing.
> Don Johnson
Does anybody think that twofish is handicapped, because B. has stepped
on a few toes?
- it's a kinda upstart'ish company, at least when compared
to the biggies like IBM or RSAlabs
- B. has blown both of their candidates out of the water and is
(IMHO) at least equal to the others.
- Counterpane is no university either, yet certainly as competent as any
university department in the field.
- B. has had a big part in the explosion of the myth of cryptography as
some kind of secret science reserved for governments and big companies
who got a lot of profit out of the users (former) ignorance.
Do you think that the "establishment" is going to resent that and
that it will influence the AES decision?
Greetings!
Volker
--
"Isn't it just my luck. Some stranger says to me, "I LOVE YOU"
and next thing I know, I've got this virus..."
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: P+1 factorization algorithm
Date: Thu, 18 May 2000 14:38:31 GMT
In article <8g0tjt$4nv$[EMAIL PROTECTED]>,
Bob Silverman <[EMAIL PROTECTED]> wrote:
> In article <8g0fs5$lgs$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Does anyone have source code, or a detailed description of how to
> > implement, the P+1 factorization algorithm?
>
> The *definitive* article to read is Peter Montgomery's
> Speeding the Pollard and Elliptic Curve Methods of Factorization
> Mathematics of Computation, 1987
Thanks, I'd like to read that, but where can I get hold of a copy? Can
it be downloaded from anywhere? Or do I have to subscribe to MoC ?
Chris
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: AES final comment deadline is May 15
Date: 18 May 2000 14:52:48 GMT
If one reviews the final comments, it seems clear that B.S. has done a better
marketing job of TWOFISH than some other algs. How much is technical and how
much is politics remains to be seen.
There have certainly been some philosophical issues raised. B.S. feels that
any SW trick, including self-modifying code, is legitimate and will be used,
hence should be used in any comparisons. Others feel this is anathema with good
programming practise. I tend to side with the latter, and so think B.S. & co.
did themselves a disservice, if they really wanted to have all-out code, they
could also have all-out code that did not "cheat" for those of that persuasion,
otherwise, one might be comparing apples and oranges.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Q: How to find good characteristics for differential cryptanalysis?
Date: 18 May 2000 15:28:24 GMT
JBR <[EMAIL PROTECTED]> wrote:
> Given an iterated cipher, how would you go about finding
> high-probability characteristics for differential cryptanalysis?
Typically by an exhaustive analysis of the various components and some
maths to demonstrate that this is sufficient.
After that, you start having to become clever.
> I've read several descriptions of differential cryptanalysis and
> understood them (for the most part, but not completely). What the
> authors didn't say was how they came up with the high-probability
> characteristics in the first place.
Usually by getting a computer to examine an S-box exhaustively. You try
every possible pair with a given difference and you see what the output
differences are. You make a huge table, and see where the big numbers
are. On a 256-entry table this doesn't take long. I just write a quick
Perl script, often tailored to the exact analysis I'm doing. (See, for
example, the script which found the 0x65 -> 0x00 characteristic for
BREAKME.)
Note that the diffusion parts of a block cipher spread output
differences throughout the block. It's important to apply some sense to
the answers you get from the exhaustive analysis you did on the
S-boxes. It's not a lot of use if your high-probability differential
has its output splurged through lots of S-boxes in the next round,
because you then need however-many characteristics to hold
simultaneously.
Particularly useful are characteristics which give you a zero output
difference.
This sort of thing won't give you information about truncated
differentials, higher-order differentials or other such whizzy things.
These, I believe, require real thought to find.
> Is there a surefire method for finding the most probable n-round
> characteristic for specific round structures?
Depends on the structures. For a cipher I'm working on at the moment, I
can't exhaustively analyse the nonlinear component so all my analysis is
statistical in nature. Some other ideas have just struck me on how to
improve this...
Good things to read, to get a handle on this sort of thing, are:
* Eli Biham's `Differential Cryptanalysis of the Full 16-round DES'.
* Rijmen and Knudsen's `Cryptanalysis of LOKI97'.
* The AES submission papers for various ciphers. The Twofish paper
has lots of good analysis in it, for example. Also read the other
research by competing cryptanalysts.
This stuff is not ever-so easy. Revise it every now and then, and it'll
start to become comprehensible and then familiar.
-- [mdw]
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Unbreakable encryption.
Date: Thu, 18 May 2000 08:21:08 -0700
<[EMAIL PROTECTED]> wrote in message news:8g0jor$p9c$[EMAIL PROTECTED]...
> I would welcome any comments on weaknesses in Base Encryption.
>
> There is a more detailed explaination at http://www.edepot.com/phl.html
> Remember, intractable problem domains like NP HARD are proven
> to be "non-brute-forceable". Base Encryption implements an
> NP HARD intractable problem domain.
Do you have a proof that decrypting or extracting a key (or some other
similar subproblem) from a Base Encryption message is NP Hard? If so, I'd
be very interested in seeing it. If not, then stop making wild claims.
--
poncho
------------------------------
From: fork <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: random.org?
Date: Thu, 18 May 2000 11:43:56 -0400
> Does anyone know the quality level of random.org? It explains what
> random numbers are and that it retrieves them from radio wave noise,
> but fails to mention whether you're getting fresh numbers, rehashes,
> etc.
> Also, does anyone know of a real-time stock market level server (Dow
> Jones preferably but any will do)?
> Obviously I'm trying to find a good source of online random numbers
> so any other sources would also be appreciated.
Well, SGI has one, search for LavaLamps. In short, they take images of
LavaLamps and get random results from it.
=================
Daniel L�onard (aka fork)
Computer Science Student
Universit� de Montr�al
"The nuclear warhead is one of the Humans' most efficient weapons. They
first tested it on themselves, obliterating several entire cities. The
intervening centuries since the weapon's first use had not dimmed its
effectiveness, as the Black Star proved when it blew apart. It was, from
all accounts, a most impressive display and took - by the standart of
such thing - quite some time as one section after another after another
of the ship erupted."
- Emperor Londo Mollari, Babylon 5 : In the Beginning
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NIST releases final AES comments
Date: Thu, 18 May 2000 17:53:39 +0200
David Crick wrote:
> I thought that a very interesting comment was the one from
> the US DoJ INS. They recommended Twofish, but with 256-bit
> keys only and with a minimum of 20 rounds, with 24 as the
> recommendation.
>
> Coming from a Government department that uses different
> levels of crypto (including spook-designed), I thought the
> endorsement of 256-bit keys and a safety margin of 18 rounds
> (from the current 6 rounds attacked by the public) was
> significant.
>From the article on the webpage of NIST 'Hardware performance
simulations of round2 advanced encryption standard algorithms'
it seems Rijndael has the overall better performances.
However, are the five candidates 'equally' strong? Probably
that's a difficult to answer question. Anyway, from the
figures there, using 256 bits do not double the time of 128
bits but amount to something less. From the wide performance
range of the 5 candidates one could legitimately ask whether
there is 'real' necessity of using 128 bit instead of 256 bit
for reasons of speed. As to number of rounds, if I ever were
to use AES, the first thing I would probably do is to attempt
to make the number of rounds user choosable. That would
certainly render the implementation incompatible with the
world but would on the other hand provide an opportunity to
tune the encryption strength in some measure to suit the
requirements of my private communications.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Interpretation of Hitachi patent claims
Date: Thu, 18 May 2000 17:54:52 +0200
I just looked into the letter of Hitachi to NIST in
http://csrc.nist.gov/encryption/aes/round2/comments/20000410-sharano.pdf
I think I could understand the 'claim 1' there, but apparently
my poor English knowledge prevented me from comprehending
'claim 10'.
Would some native English speaker kindly translate these
claims into (mathematical) symbolic form so that we could
jointly study and discuss them and eventually detect some
weakness in Hitachi's claims in relation to the AES
candidates?
Thanks in advance.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: AES final comment deadline is May 15
Date: 18 May 2000 15:48:53 GMT
DJohn37050 <[EMAIL PROTECTED]> wrote:
> There have certainly been some philosophical issues raised.
> B.S. feels that any SW trick, including self-modifying code, is
> legitimate and will be used, hence should be used in any
> comparisons. Others feel this is anathema with good programming
> practise. I tend to side with the latter,
The usual definition of self-modifying code is that it's code which
changes /itself/. The problem with self-modifying code is that it's
hard to see what the code does if it keeps changing. (Usually the parts
that change are actually bits of immediate data, such as addresses, and
it's not that difficult to work out what's going on if you know the
platform.) What the Twofish team's code does is generate a /complete/
function which does Twofish encryption with a fixed key. It gets
generated somewhere where there wasn't any code before, and the code
generator doesn't itself change. I think that's a (JIT) compiler, not a
piece of self-modifying code.
If you disagree, tell me what you think the difference between
self-modifying code and a JIT compiler is.
-- [mdw]
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Base Encryption: Revolutionary Cypher
Date: Thu, 18 May 2000 15:49:51 GMT
[EMAIL PROTECTED] wrote:
>
> The following is a description of Base Encryption.
> The only Cypher that is not susceptible to Brute Force
> Attacks.
>From the Snake Oil FAQ:
( http://www.faqs.org/faqs/cryptography-faq/snake-oil/ )
[...]
Unbreakability
Some vendors will claim their software is ``unbreakable.'' This is marketing
hype, and a common sign of snake oil. No algorithm is unbreakable. Even the
best algorithms are susceptible to brute-force attacks, though this can be
impractical if the key is large enough.
[...]
Technobabble
If the vendor's description appears to be confusing nonsense, it may very
well be so, even to an expert in the field. One sign of technobabble is a
description which uses newly invented terms or trademarked terms without
actually explaining how the system works. Technobabble is a good way to
confuse a potential user and to mask the vendor's own lack of expertise.
[...]
> Base Encryption solves the weakness in todays encryption schemes,
> namely...
>
> Fixed symbols (base)
> Fixed keylengths
> Fixed algorithms (fixed number of operations and operators)
Some mathematics:
1) One bit increase in key length adds n^2 additional strength (where "n" was
the additional key length), assuming the cipher itself is strong. That is, it
adds n^2 additional operations to brute-force it. Thus going from 128 bits to
129 does not double the number of operations -- it squares the number of
operations needed to brute-force the cipher.
2) Adding other algorithms to the encryption program and randomly selecting an
algorithm adds at best 'n' additional strength, where 'n' is the number of
algorithms (that is, requires 'n' additional operations in order to
brute-force it). However, what I understand is happening here (based on the
technobabble) is key-dependent transformations to the actual encryption
algorithm, which have a long history of actually REDUCING the strength of
algorithms because the output tends to leak key information. Study why DES
used fixed "S" boxes and why TwoFish also has some fixed "S" boxes (as well as
some key-dependent "S" boxes to handle other attacks).
3) Adding other bases and randomly selecting a base adds little if any
additional strength. All bases can be represented in base 2, albeit with some
wasted bits for odd-number (non-power-of-2) bases. Adding other bases thus
can be considered to be a very crude block-cipher diffusion mechanism, i.e., a
mechanism for diffusing bits across a larger field of bits, with some
properties that make it decidedly inferior to most such mechanisms for
transforming bits (for one thing, a 1-bit change in the input does not have
the desired avalanche property).
Based on the above, it is clear that the easiest way to get better security is
to use a well-designed cipher that uses well-thought-out transformations with
desirable diffusion and avalanche properties, with an adjustable key size,
such as Blowfish, and simply add a few bits of key material.
> All the current modern encryption algorithms utilize fixed symbols for
> plaintext and cyphertext. What I mean by fixed is that there is a set
> and limited number of symbols to represent the characters, numbers, and
> punctuations. In addition, they are usually the same (the plaintext
> symbols have the same and equivalent counterpart in the cyphertext
> symbols).
Sigh. From the snake oil FAQ:
Revolutionary Breakthroughs
Beware of any vendor who claims to have invented a ``new type of
cryptography'' or a ``revolutionary breakthrough.'' True breakthroughs are
likely to show up in research literature, and professionals in the field
typically won't trust them until after years of analysis, when they're not
so new anymore.
I already touched upon the 'base' bit up above. Note that all modern computers
operate using base 2 arithmetic, thus all input and output symbols are
ultimately decomposed to a string of 1's and 0's. Thus this guy is proposing
to do a key-dependent transformation to a different set of 1's and 0's and
saying (seriously?) that this is a better transformation than the
transformations usually incorporated into Feistel-type block ciphers. Of
course, avalanche and diffusion properties of his transformation are almost
non-existent, but why should little things like facts matter?
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Base Encryption: Revolutionary Cypher
Date: Thu, 18 May 2000 17:57:48 +0200
[EMAIL PROTECTED] wrote:
> The following is a description of Base Encryption.
> The only Cypher that is not susceptible to Brute Force
> Attacks. (besides the One-Time-Pad of course :)
>
> HTML version: http://www.edepot.com/phl.html
The following are my (non-expert's) comments on your
article. Please don't interpret these as any intentended
malicious attempts to diminuish the value of your work.
One has however to discuss to determine what is true,
valuable or novel in an article in the spirit of science.
1. You critique that up till now plaintext and ciphertext
are in fixed bases, and in particular in ASCII, is not
founded. Modern encryption algorithms take input
principally as sequences of bits, either as blocks
of certain constant size (in block ciphers) or of no
fixed size (in stream ciphers). The algorithms don't
care in which base the plaintext is to be interpreted
to become meaningful to the user. But certainly there
has to be one certain base in any concrete given case.
Ciphertext is normally regarded always as a sequence
of bits. But for transmission, e.g. via e-mail, one
may desire to convert that to hexs.
2. Base conversion could facilitate certain encryption
processing, if suitably done. This is however not new.
wtshaw of our group has posted quite a lot of that
in the past. I have asked him (recently a second time)
to present a basic description of his work for
discussion in the group.
3. You 'symbol remapping' is 'monoalphabetic substitution'
of the classical cryptography. Similarly your
'duplicate symbols' is 'homophones'.
4. Dynamic encryption algorithms exist in diverse forms.
In parametrized ciphers, the user can choose the values
of different parameters to obtain different exemplars
of the algorithms out of the class of algorithms being
parametrized. One can have variable key lengths,
variable block sizes, variable number of rounds,
variable keys, variable subkeys, variable S-boxes (both
content and ordering), variable chaining modes, etc.
I have in the past attempted to use the term 'principle
of variability' in issues of cipher design. The
variability can essentially contribute to the difficulty
that the opponent faces. However, one could regard it
also as equivalent to extending the length of the key
employed. If one uses multiple encryptions, i.e.
superencipherment with a number of encryption algorithms,
then the choice of the algorithms (from a number of
candidates), the number of these and the ordering of
these are all dynamic features of the scheme. On the
other hand, I am ignorant of published schemes having
parametrized operations (e.g. user choise between xor
and add). Once I did attempt to incorporate that into
one of my humble designs, but I finally discarded the
idea because I thought that would much complicate the
coding without resulting in proportionately high
benefits in return.
5. 'Unbreakable encryption' is, in my humble opinion, a
term that you should avoid to use, independent of how
strong/good your encryption scheme really is. For
that can't exist in the real practical world, like
'perpetum mobil'.
M. K. Shen
==========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
Date: 18 May 2000 15:56:04 -0000
From: [EMAIL PROTECTED]
Subject: Re: random.org?
=====BEGIN PGP SIGNED MESSAGE=====
On Thu, 18 May 2000 11:47:29 GMT, Tom St Denis <[EMAIL PROTECTED]> wrote:
..
>Note that this info is *public* and will not suffice (no matter how
>random) for a secure rng/prng.
They state as much
"As mentioned in my essay on randomness and random numbers, true random
numbers can be used for many purposes, perhaps the most important of which
is the generation of cryptographic keys. Numbers from random.org shouldn't
be used for this purpose because they might be observed by a third party
while in transit, but there are other applications (most notably games and
lottery type services) that require true randomness but where secrecy isn't
important."
(part of top paragraph at http://www.random.org/users.html)
Katt
=====BEGIN PGP SIGNATURE=====
Version: N/A
iQEVAwUBOSQRmkhgZ0qbzxhRAQHsHQgAjEvg+TWlRGw2Hf34neyu4KR0ZpXcRqpL
IqwFBfor2yr9xsplgk304RNDUDa8ZYlNYBQHP/AGIvWeskln9VBlMBX8TTWGFeLs
O6JxtJ5kMjlhQ/USH8skrFBmpfn/jNE8xsunvRiM94Baae01HpZukhhtR20yc12U
1eehUWcNayWkBUUyKSLoMhiFcnI9b3XW889ZRo2wyqKRalfQJBYu+rfW3naBF3ax
QilKFj6eDRL/AsZsyZlxkD12UII1CYYegZGvtI++ecLPMY5Q9wkcd94RW2GsFZo9
rU45dq97G0kK9WNgIVy3TLHjpg76Wvi/OcdPKiYLNyjs2XR3P3AOAw==
=Xy4U
=====END PGP SIGNATURE=====
------------------------------
From: "Karim A" <[EMAIL PROTECTED]>
Subject: PADDING problems
Date: Thu, 18 May 2000 17:52:20 +0200
Reply-To: "Karim A" <[EMAIL PROTECTED]>
Hi all,
I've coded Blowfish algo in ECB mode,
it works very well but I just encountered some bugs due to paddings.
My plaintext are not multiple of 8 bytes.
Can anybody give me some tips about padding to resolve that ?
And what about "ciphertext stealing" ?
What's the best solution ?
Sample code is really welcome ;o))
Thanks,
Karim
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Unbreakable encryption.
Date: Thu, 18 May 2000 15:58:59 GMT
[EMAIL PROTECTED] wrote:
>
> For all practical purposes, representation of infinite numbers
> is not a problem. Numbers can be placed in a rational form
> like 1/3 instead of .3333333333. For encryption's sake, predefined
> precision can be agreed upon before the calculations,
The 'predefined precision' is part of the key. Note that "key", in the context
of cryptography, is "all information needed to decrypt the ciphertext". You
are still engaged in the transformation of bits from one form to another. I
submit that your transformation has decidedly inferior properties
(specifically, avalanche and diffusion) as compared with the transformations
typically used as part of typical block ciphers.
I would most strongly suggest buying a basic book on encryption such as
"Applied Cryptography" and reading it before further humiliating yourself. You
are ringing so many bells on the Snake Oil Faq's list of bells that half the
news group is laughing at you and the other half is just shaking their head in
amazement. http://www.faqs.org/faqs/cryptography-faq/snake-oil/ in case you
have not read the Snake Oil FAQ lately.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?
Date: Thu, 18 May 2000 15:59:49 GMT
[EMAIL PROTECTED] wrote:
> I am pretty convinced that some of the non random pattern of the
> plaintext shows up in the ciphertext...
Nope.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: sci.crypt cipher contest
Date: Thu, 18 May 2000 15:47:49 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mark Wooding) wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > The server is in the states (to the best of my knowledge) so there
is
> > no problem sending papers to him. It's just going the other way.
> >
> > Personally I wouldn't worry about it.
>
> I thought that current ruling was that source code was protected free
> speech and regulating its export was unconstitutional. Or was that
last
> week? ;-)
AFAIK the states still have crypto export laws, they just allow for
bigger domestic keys now.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Please help to decipher
Date: Thu, 18 May 2000 15:49:51 GMT
In article <8g0sn3$3ce$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I know a part of the permanent key and would like to find the rest.
> The key is used to hide IP packets content, it just combined with
> data by XOR operation. As far as I know the beginning of each packet
> I could find the beginning of the key.
>
> I tried to find all the key in the executable and than in core dump.
> But seems like it's not a predefined sequence but some hash(?)
> function.
>
> So, the question is, which function might generate the following
> sequence:
>
> 160, 112, 205, 2, 44, 135, 43, 214, 190, 149, 184, 170, 68, 209,
> 163, 245, 37, 153, 2, 30, 179, etc. (64 known values)
>
> Is there any software to dig up such sequences?
If it is a repeated-xor (Vinegere) cipher then just encrypt 256 or so
known bytes...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Unbreakable encryption.
Date: Thu, 18 May 2000 18:11:34 +0200
[EMAIL PROTECTED] wrote:
> For all practical purposes, representation of infinite numbers
> is not a problem. Numbers can be placed in a rational form
> like 1/3 instead of .3333333333. For encryption's sake, predefined
> precision can be agreed upon before the calculations, and it can
> then use truncation, or rounding to deal with the extra precision
> point. There are options to set the precision in the calculator,
> which does not preallocate any storage (so it uses memory only
> when necessary). Large values in memory can be virtually dumped to
> disk and retrieved when needed,
> and is handled automatically by many OS's these days (look up
> virtual memory, swap partitions, etc).
It is yet 'entirely' not clear to me why do you need real arithemtics
of infinite precisions in encryption at all. Could you show an example?
M. K. Shen
------------------------------
** 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
******************************
