If you understand how rules create behavior in exclusionary rings then
it is easy to understand the coverage problem of the ring of algebraic
integers by considering what certain things proven in that ring mean
mathematically.

For instance, consider a number N which is proven to NOT be a unit in
the ring of algebraic integers.

What does that tell you?

Well, first a number is an algebraic integer by the rule that numbers
which are roots of monic polynomials with integer coefficients are
algebraic integers.

It can be further shown that to be a unit in the ring of algebraic
integers a number must be the root of a monic polynomial with integer
coefficients and a last coefficient of 1 or -1.

So there is ANOTHER deeper rule created by the first parent rule, which
is that to be a unit in the ring of algebraic integers certain
additional conditions must be met.

Then what do you know about a number N that is proven to not be a unit
in the ring of algebraic integers?

I've recently made a program on a TI - 83+ that takes a password, and
multiplies it together. ie if the pass was HAT, then H=8 A=1an T=20 so
HAT = 8*1*20 = 160. this number is then used as a random seed. The
binary data (accually a picture on the calculator due to its
limitations) is then changed using a xor on the random number and the
original data. the random number goes through some changes so its
either a 0 or a 1, but thats irrelavent. If the data is decrypted with
the wrong seed (password in this case) the data will be totally
illegible. but if 160 is used again as the random seed, the original
data will be back to normal. I'm relativly new to cryptography, so if
this has already been discussed, discovered, or is pointless, I
apoligize.

Hello:
I'm studying various resources on ipsec used in ipv4 and v6. I know
that it is optional in v4,but mandatory in v6. But is there any
security feature of ipsec(in terms of new encryption mechanisms and
anti-address spoofing properties) that is prescribed in v6 but not
available for v4? Thanks.

So, lets say I want to create a secure messaging system based on public
key crypto. I start with something like PGP. Peoples may or not have a
Key Pair, so there are 4 ways to send a message:

1) Not signed, Not encrypted (neither sender or recipient has keys)
2) Signed, Not encrypted (recipient doesnt have key)
3) Not Signed, Encrypted (sender doesnt have key)
4) Signed, Encrypted (both have keys)

So now, I decide I'm going to have an Signature Scheme, and an
Encryption Scheme. For now those are independant Schemes.

My Signature Scheme is basically going to be a Hash on the Plaintext,
and then a signature primitive, such as RSA or ECDSA, on this hash.

Now I want my Encryption Scheme to be safe against Chosen Ciphertext
Attacks, so it includes a MAC on the Ciphertext.

So now basically I have three operations that operate on the full
message data:

1) A Hash on the Plaintext
2) A block cipher on the Plaintext, this gives me the CipherText
3) A Mac on the Ciphertext

Due to the size limit of the signature, I can only use 49 bit prime
field. The library I plan to use is MIRCAL. ECDSA is described at
http://en.wikipedia.org/wiki/Elliptic_Curve_DSA. I'm wondering how hard
it would be for someone (regular Joe with a regular desktop) to break
this 49 bit prime field signature schema.

Many thanks to Kristian Gjøsteen for pointing me to the right
direction.

Thanks in advance.

I've implemented an alleged RC4 algorithm
(http://en.wikipedia.org/wiki/RC4). I think I've done enough in a
slightly modified version, called modcrypt. Any analysis of the mods
are welcome, and as an incentive, I'll offer $200 to anyone who
decrypts the challenge.enc file.

The changes are:
* Adds the plaintext character to j as we encrypt/decrypt. This
enters any entropy in the compressed data into the S table. I find the
arguments against this tactic to be quite unconvincing. The benefits
are having a nice checksum, and distributing data well, thus enhancing
security.
* Reduces nonce value to 20 bytes - 160 bits should be enough.
* Reduces discarded bytes to 512 - There's no evidence on the net
that more are needed.
* Simplifies mixing of the password and nonce values with the key,
since throwing away the first 512 bytes mixes them up anyway.

I'm just an amateur here, so any help is appreciated. The site to go
to is tinycrypt.sf.net. The file to analyze is modcrypt.c (in
tinycrypt_0.37.tar.gz).

We have a webserver that is running windows 2000 SP4. Our server
generates letters which pulls its logo/letterhead from an images
directory via HTML tags. The images are .jpg format. Well recently we
enabled SSL because of HIPAA policies. after doing this our images were
inaccessible. We rewrote the code to look in either http or https. the
images started pulling again. When we generate a letter it displays a
copy on the screen, which will allow you to print. When you print it
some times and very sporadically the images will not print. There is
also a copy of the letter saved in the system and when we open it to
reprint, the image is there and it will print. when the letter displays
the first time the image is there as well. It's pretty hard to tell
when the image will not print because it...