Let N be a positive integer. Let M be a n integer relatively prime to
N, and let d be an integer relatively prime to \phi(N), where \phi(N)
denotes Euler's \phi function.
Prove that if M*=M^d(mod N) then M=M*^d*(mod N), where d* is the
inverse of d (mod \phi(N)):
dd*=1(mod \phi(N)).

given that i am generating an 8 character hex block which will give
collisions every 2^46 times, and that i am using a chain of blocks to create
the internal state key, 1 block for each character in the passkey, so an 8
character passkey will produce 8 hex blocks of 8 characters long, a 64
character internal state key. does it stack? by that i mean if it's 2^46 for
one hex block, is it 2^92 for 2 blocks, 2^138 for three blocks etc.

I've been messing around with the code for an older PC game called
"Aliens versus Predator". I've managed to add a few things to the Linux
port and I'm working on a few others.

One irritating thing is that the files are stored encrypted on the
install CD, and the Windows install executable (that does the
decryption) doesn't easily work under Linux. You need to use VMWare or
a real Windows box to install the files. After that you can copy the
game data to Linux, but installation is a bit of a pain.

I've been looking into how hard it would be to break the encryption on
these files. (Note: I am *not* trying to violate copyright. I'm just
trying to make it possible to install these files from a valid CD under
Linux.) Since I have decrypted versions of these files from a Windows
install, it becomes basically a known-plaintext attack.

I've done some (very) simple checks - e.g. some simple XORs of the
encrypted and plaintext versions, by byte or short or integer. No
trivial solutions, but it's clear that it's not a complex algorithm -
comparing a plot of the plain file vs. the encrypted one, you can see
that different 'regions' of the files look different.

There's a new show starting tonight on Channel4 (UK) about
cryptography.

The show looks like it's going to be a history orientanted show with a
Cryptogram as the thread running through the show.

The initial Codex can be found at:

http://www.channel4.com/history/microsites/C/codex/pdf/codex_week1.pdf

or (if you can't be bothered with the symbols)

ab cdeefe abg fheihg'i eaj; fha'k fbakhla hk hdd, ieen hokopahd chdd.

Not very difficult to solve but may make for an interesting show. The
answer to the Codex this week is below.

There's a new show starting tonight on Channel4 (UK) about
cryptography.

The show looks like it's going to be a history orientanted show with a
Cryptogram as the thread running through the show.

The initial Codex can be found at:

http://www.channel4.com/history/microsites/C/codex/pdf/codex_week1.pdf

or (if you can't be bothered with the symbols)

ab cdeefe abg fheihg'i eaj; fha'k fbakhla hk hdd, ieen hokopahd chdd.

Not very difficult to solve but may make for an interesting show. The
answer to the Codex this week is below.

SPOILER BELOW

NO FLEECE NOR CAESAR'S END; CAN'T CONTAIN AT ALL, SEEK AUTUMNAL FALL.

I have two peers that are communicating using IPsec and IKE to establish
their SAs. One of the peers, call it peer A, always initiates conversation
with the other, peer B (never the other way around). It seems that if peer
B resets (or otherwise loses its IPsec SA information), then peer A will not
be able to initiate communications with peer B until peer A's SAs expire
(peer A at the OS layer has no idea that peer B has lost its IPsec SA
information), as peer A will be encrypting via its existing IPsec SA. Is
this true? Is there a way to 'correct' this at the IPsec layer? Thanks!

I would really appreciate if someone could give me a hint
how these floats are encoded:

0B7D2F70 41.8713
0B7D232F 41.8687
0B7D220F 41.8684

This is not IEEE-754: http://babbage.cs.qc.edu/IEEE-754/Decimal.html

Thanks in advance

Vadim

DXAKRWZHWHWWSRNIOJHRSRXICSQBVOVYHHCDBHILBCLQBCZEMARZJICBYSPZVMVLLVARKNPBAQKHYTBTMMTFKKQ
VEPGWFJNLONZYABAWRKSFCZVCPJDCDJXFWOTXRVGUOSWCNTYCMQGTRDFYPEKUXLFBZUSVUTTHQJIPRWQCTEQMB
MLTHTHNTJDCCHCOLXDJCOIFVICKHSNNGEMCALYDNIDXOUDOFUHKJOHIRMTVDSOJHDITSRYIGBYLPJBKREJJESBMEJIJO
CAZEQCQJAUZSUUTALKDKHZKDOVOFMXUNEEBVQMWBXWFNMQISYPGCEROSWEAEBYGMPVRYUONNJTKNKQRVHOFUZ
CGEKRWWBKXWEIRFQBUPDZJWYXQNEJHXVTJHRFAPZHMQKAOGYYVRUCOQMIJAXQJLQFNZHAHPCZCHMZZLJEHHTCSE
NYBNCYOQWJMWTGZSOKKFIOFALYSNTHNNAAEEKHCMJOONJXDGHQEGPNDUIQZVTKTZCMNZJMDEFKOGZLXSIWDTZVU
ZAJVDARRYRKOGORCDRTNBYCMFXJQGKRAXOQMCWVGJJZKTVQAPMUCQDGKTYNTXDVSULBKJOWJDBRAXSYXTETLTAE
QYCISSYSIXIPOJOYNRPPHPHYLLVEISQPDMLNMSVFBWJUXJASYKECILUJCKHSXNEWWPWOWSNRDJOLRZVGDHZLJXCWY
GPGWDEDMYHURYSBGKJRYOHLREQZQMBCGGIYVYMSCTVTNZUPASFFBYOBAHUOXZLZOBTFNQFWRVVSYBQAKRSFQZJN
EGDWEKWFCHHHGGTWTBPQBGLJCBOTODTLEEUWDHHUOSWKFNQTSUGVWPIQDXMXIEINXWSIWIPLURFEEWKIFUGYRF
ZAVTQBXTZRARUBWMMTEUREFYRCTGJEMXYSPBUQTWVDXESYGTLULJSPOUIDTVOUXGEEDKSMCZSNECCRXIWUGTVR
KFEHDEQAIHQIGBWHFAMTEDBNXHUUCGIPRNPXEXIWWBDUBRIWXGMHSIDWXSYVHMQCEXMCDFCRQVBRJXHAYPQKSP
GONEKURMSTPZSVXBMWVWZQEQUHWSFYLPKHAFMGVQPUOKUCWOPPRIQKUINUINGHQXWBQNTTIMRHMJKGUXQTFC
TMELGLPBSXKNDMDZVCHYGSBPRHCBTJIYLBYYEQNPOUECESZQSIXBXBFSQNUDZOGWBAALOJGICBUGSCAHZTAFHOABN
OGPGJOBLJCSVDSNXHUOUCUBRQKRTYZZIETKOFVNILDTRGQZOJBMAVBVUEJVGPWGFRGIZXLKKOPRMBWGXAZRKAHQPH
UWUBWGXHFDTTXCYTIEXISYZMKSUVAVDAJCGWLJULSEXZPAGLQYRIPZRFAHZORPQCCPDVMKUFBBDLXUCRVEVEFGZXO
OMXPLUOBOTCDRXGCTERPAZVEAHJQASMQNNPXSYIWPXINNTVAIQDTYALJJKCOJPMRJORDEAKEQBVXDWJTDRAHEFWA
WWJBSMKASYDDIBOMPQGBYICVTXLGFYOHDBBJQZCCETTSQKGVWMZGNLFOGISQMVUCPAGLZWBLLSYGMAJQUCJMHVD
TQDWPFAFMKBFTAYZKISFWTICCWBCHHBEMNUQLKCKCMVTGKLEEWWBGMAYJFEWCELQZNPIZLTTBAEQWERNBAOXFJX
MVLAWUFIAATJADYUWHWWHUINTYFTYGMMZAFLKLDGRVCLDQHTQJXGXGKACMTLFOZBDNILEMWEJGNLPENOUFIHQMCF ...

Most experts argue that the quantum computers (QC) will require change
of assimetric key encryption systems. That is, the factorng of a large
number will no longer be a diffucult problem, since QC will be able to
use all possible values for prime numbers simmultaneously hence
yeilding correct pair which factors a given long number in several
clock cycles.

Now it seems to me that the problems with using cryptography when
attacker has a QM will not stop there. It is customary o assume that
attacker knows the encription algorythm and can intercept lots of data
encrypted with the same key as the messege he is trying to decrypt.

So if attacker is trying to breake encrypted text E2 and has plain text
T1 and its encrypted version E1, using the same key as used for E2, all
attaker has to do is to find a key which decrypts E1 into T1. If
quantum computers can do basic math they also can do more complex
operations, which will take loger, but will just like basic math use
all possible input output values simmultaneously, hence atacker can use
all possible keys in 1 operation (here operation is not a clock cycle
but a time required to do 1 encryption) to encrypt T1 into En and see
which En=E1, hence yeilding the key for E2.

hockeyboxbaseball@fastmail.fm wrote:

Do we ignore this one too?
Since it came from Google just like the in-crowd here?