Not every UK scientist would want to move to
the US to find a job. Those involved in areas
that are currently restricted in the US (new
stem cell line work, certain types cloning)
would find the entaglement in the US even worse.
I found that it was easier to sit down with my
PM and asked then the one thing they needed to
make their job easier. If it was half way
reasonable I went out of my way to give that
to them... in turn they seemed more willing
to listen to reason and help form a project
timeline that was 1/2-way based on reality.
''This is the first 'book upgrade' I've ever
heard of.''
Back in the days when computer documentation was
only sent out in dead tree form, those
loose-leaf books/binders were upgrade/updatable.
CDC manuals, back in the 1970's, came with a
free update service that continued well into
the late 1980's.
do-it-yourself one time pad
on
Encryption by Hand?
·
· Score: 5, Informative
For a non-public key stream cipher:
If you allow the addition of dice, say a d20...
Setup by the sender:
Generate a one-time pad by rolling the d20
and writing down the 1's digits (d20 face value
mod 10).
Transmit the one-time pad in a secure fashion
(use somebody's public key suggestion, hand carry, etc.)
Setup by the receiver:
Receive the one-time pad from the sender.
Store in a secure place.
To encrypt:
Convert each plaintext symbol into an alphabet
of 100 values (00 thru 99).
For each plaintext digit, remove a digit
from the one-time pad and transmit the sum mod 10.
Destroy the used digits of the one-time pad.
To decrypt:
Receive the cipher text from the sender.
For each digit in the cipher, remove the
next digit from the one-time pad and subtract
mod 10, from the cipher digit.
Convert the result, pairwise,
(00 thru 99 alphabet) into plaintext symbols.
Destroy the used digits of the one-time pad.
Encrypt example:
Plaintext: Hello
One-time: 9690367034
Alphabet: 0730373740
Transmit: 9320630774
Decrypt example:
Receive Ciphertext: 9320630774
Receive One-time: 9690367034
Subtract mod 10: 0730373740
Convert to text: Hello
And yes, the devil in the details is
in the secure transmission of the one-time pad
(step 2 of sender setup).
Key management is never easy.
Storage and transmission of one-time pads is
one of the reason why this form of crypto
is not a realistic choice for most applications.
However if you have some way to transmit the
one-time pad ahead of time, say visiting the
sender ahead of time and dropping off the one-time
pad it is not a bad choice.
While you may not need a ventilation hood, you
should not store liquid nitrogen on a closed
room.
Pay attention to where the chilled nitrogen
gas (that has just boiled) is going.
Don't store or operate it near the top of
stairs that lead down into a sealed room or
basement as the chilled gas will flow downstairs
and displace some of the air in the lower room.
You should not have a problem if your rooms
have reasonable ventilation / air flow.
Be careful of chilled metal
You can pour some amount of liquid nitrogen
on your hand without a problem because
the heat from you hand will form a boiling
vapor layer and protect your hand for a while.
On the other hand if you dunk something into
the liquid nitrogen and chill it and then touch
it, you can get a serious burn.
A wire or aluminum plate
that has been chilled to or
near liquid nitrogen temperature will burn you
almost instantly if you come in contact with it
while it is still cold.
Watch for icing and water hazards
Ice and water can form around equipment where
liquid nitrogen is boiling.
The water runoff can ruin your hardware.
The water can present a shock hazard as well.
Be sure that your equipment is well grounded.
Do not touch your system unless the power cord
has been removed.
Many motherboards and power supplies
have electricity flowing in them
even when the system is off.
Always unplug before opening the system
to reduce the risk of water
condensation shock.
Be careful around young kids
The liquid nitrogen is a attractive hazard for
kids.
Be on alert of kids live or regularly
visit where liquid nitrogen is in use.
While you may take reasonable care,
young kids may not.
Young kids who see adults
working with liquid nitrogen
may get hurt if they try to play with
it on their own.
A young child can be seriously hurt if they
try to touch or drink what they think is
funny looking water.
So you are saying EC is vulnerable due to that it requires "only" 2^128 ops to crack and it can even be parallelized?
No, that is not what I am saying.
EC is more vulerable than RSA for a given key
size where the CPU ops to perform the best known
cracking algorithm are the same.
CPU-op equivalent EC searches
require only a modest amount of memory and can
be run in parallel with nil communcation
requirements.
CPU-op equivalent RSA searches require large
working sets with matrix operations that do not
lend themselves to parallel operations once the
initial sieve is performed.
Even if you deploy a TWINKLE device
in an RSA key crack that reduces
the initial loading of the matrix to nil, the
working set size of the matrix, the swap and/or
system communication requirements become
non-trivial for an CPU-op equivalent RSA key.
The paper suggests a way to improve some of the
steps required (such as some of the linear
algebra work) to factor using the Number
Field Sieve (NFS) for large keys.
The paper does NOT give a method to
improve the speed of cracking EC keys.
Special purpose hardware could reduce the cost
of cracking an RSA key.
However: The same could be said of cracking an
EC key.
Using different special purpose hardware
and different performance tuning, one
should be able speed up cracking of EC keys
as well.
So... If the existence of ideas to improve
the speed of cracking sufficiently large RSA
keys scares you and you worry about that
might come next,
then you should be even more worried about EC.
Why? Not because of the exact idea
outlined in the paper.
The paper does not apply to EC.
Because EC is subject to
special purpose hardware improvements:
perhaps even more than RSA.
... and because
while two keys, one EC one RSA may require
the same number of CPU cycles to crack,
the key crack requires only a modest amount of
memory, even for large EC keys. The RSA key (by
factoring) requires a larger and larger working
sets as the key size increases.
A common mistake that some people make is to
assume that one only needs to count CPU cycles.
The so-called "MIPS years" measurements.
Consider two keys that require
the same number of CPU cycles to crack,
one Elliptic Curve (EC)
and one RSA.
The EC key crack requires only a modest
amount of memory, even for large EC keys.
The RSA key (by factoring)
requires a larger and larger
working sets as the key size increases.
Consider the cracking a
256 bit EC key and
the cracking of a 1620 bit RSA
key by factoring:
Both efforts require about
the same number of CPU operations.
The EC crack requires only a modest amount
of memory (a handful of Megabytes) and can
be performed in parallel over many machines
with nil communication between them.
The RSA crack requires a working set of
about 120 TBytes (120*1024 GBytes)!
On a single machine, you will need ~2^47
bytes of ram in order to not to swap to death.
Worse yet, you are evaluating a Matrix.
You could try and split it over many
machines but them the communication between
them (as you perform row/col matrix ops)
will kill you.
So when I said two equivalently hard keys
I should had said:
two keys that require the same number of
CPU operations to crack.
Two keys can require the same number of CPU
ops to crack. However, a 256 bit EC key
needs only a modest amount of memory and can
be cracked on many machines running in parallel.
A 1620 bit RSA requires a HUGE 120 TByte
matrix sitting in a single address space
where swapping and/or inter-processor
communication become a major problem.
Alternatives such as EC may be vulerable as well
on
Factoring Breakthrough?
·
· Score: 3, Interesting
Some have suggested that people should move
away from RSA crypto and start using
Elliptic Curve (EC) crypto.
In fact the
paper,
if
appicable to "useful" key sizes, suggest that
the opposite is true.
The methods described in the
paper
can be used to improve the cost of
cracking
EC discrete logs as well.
The author, in a recent
Usenet
posting,
points out that the paper's methods are likely to
reduce the cost/effort of EC key cracking
as well... perhaps even more than RSA key
factoring.
The paper, combined with other
other
EC strength
concerns suggests that EC is not the technology
to turn to at the moment.
In other words, if this paper has you concerned
about the security of RSA keys by factoring,
then you should be
even more concerned about
the safety of Elliptic Curves as well.
But as others, including the author, have
stated (in large friendly letters): DONT PANIC!
It is not known if the ideas expressed in the
paper are applicable to key sizes that are
in common use.
for more details.
In short: Given two equivalently hard keys,
one EC and one RSA, the EC key will require
memory and less memory/CPU bandwidth and
will be cracked for less cost using the
state of the art methods we known today.
NOTE: These art includes: THINKLE and
NFS improvements including those discussed
in the paper (on which this discussion thread hangs).
Worse for EC: It is an active field of research.
Every so often somebody publishes yet another
eliptic curve special class that can be
cracked much faster than brute force.
In some cases it is very hard to determine
if a given EC belongs to a weak key class.
While these are mostly theoritical, the
smart cryptologist will view them as
troubling for EC key securiy at best.
can be configured to block
frequent spammer IP addresses from your SMTP ports.
The following is a list of IP addresses that we
have observed spamming on a regular basis.
Blocking these sites won't solve your spam problem.
On the other hand blocking common
spam locations as part of an overall anti-spam
system will help.
Sorry if your IP address is in the above list.
If you are not a spammer then it could be that
you happen to be using an ISP that tolerates
spammers (or is unable/unwilling to block them),
or you work for a company
that spam,
or you are near a poorly configured and
poorly maintained site that is abused as
an open relay.
We have seen SNMP scans at a rate of
about 17 per 4 hours (~6/hr) as
of 2300 PST.
The rate has been steady for the
past 23 hours. One would expect the
scan rate to increase as the exploit
tool gets into the hands or more
script kids.
Prior to this week it was rare for
someone to probe the SNMP ports.
The scans are talking the IP address
space in pseudo-random order.
It appears to hold the top 16 bits
constant
while walking the lower 16 in a
pseudo-random order.
We have not seen simple
SNMP scans that just walk up the IP address
range.
It appears that the tool is initially
just looking for open SNMP ports.
The tool could be
simply collecting open SNMP ports for later
system cracking.
Important factors for photon pulses
are the flux and the ability to
trigger the event.
We have had single photon emitters for a while.
A single photon: It about as short of a pulse as
you can get. Just not very bright.:-)
What is exciting is about
this result is they have achieved
a very short controlled
photon pulse of a non-trivial brightness.
Pardon me for what may seem like a troll post,
but I cannot help wonder if these site/org
is for real.
They call themselves CCCP... a pun intended
or an early April fools joke?
And their
web site:
Red background with Yellow letters. If not
a visual pun, it shows poor color choice in
terms of readability.
If their web site is poorly designed, what else
is in questionable shape?
If you're using grub and want a quick
but effective workaround, then edit
your grub.conf file, which is usually
under/boot/grub.conf or/etc.
On the end of any
line that begins with
the word kernel add:
mem=nopentium
For good measure, re-install your
grub config by running:
/sbin/grub-install/dev/hda
Where
/dev/hda is your boot disk.
For most PC users with IDE drives, it will
be /dev/hda.
Slashdot Mirror
Not every UK scientist would want to move to the US to find a job. Those involved in areas that are currently restricted in the US (new stem cell line work, certain types cloning) would find the entaglement in the US even worse.
err ... s/asked then/ask them/ ... suffering from being up to late working
on a project. :-(
Errr ... s/ypu/you/g *sigh*
I found that it was easier to sit down with my PM and asked then the one thing they needed to make their job easier. If it was half way reasonable I went out of my way to give that to them ... in turn they seemed more willing
to listen to reason and help form a project
timeline that was 1/2-way based on reality.
Back in the days when computer documentation was only sent out in dead tree form, those loose-leaf books/binders were upgrade/updatable. CDC manuals, back in the 1970's, came with a free update service that continued well into the late 1980's.
If you allow the addition of dice, say a d20 ...
Setup by the sender:
- Generate a one-time pad by rolling the d20
and writing down the 1's digits (d20 face value
mod 10).
- Transmit the one-time pad in a secure fashion
(use somebody's public key suggestion, hand carry, etc.)
Setup by the receiver:To encrypt:
To decrypt:
Encrypt example:
Decrypt example:
And yes, the devil in the details is in the secure transmission of the one-time pad (step 2 of sender setup). Key management is never easy. Storage and transmission of one-time pads is one of the reason why this form of crypto is not a realistic choice for most applications. However if you have some way to transmit the one-time pad ahead of time, say visiting the sender ahead of time and dropping off the one-time pad it is not a bad choice.
Best of Show
Most likely to amaze
Best abuse of the rules (Most complete program)
Best X11 Game
Best Short Program
Best position-independent code
Best Abuse of CPP
Best Abuse of User
Best One-Liner
Best curses Game
Most eye-crossing
Most obfuscated sound
Best primal ASCII graphics
Best AI
Worst driver
There was the Bill Gates award that was given out back in 1993.
On a slightly related topic, one can use the Best Utility from 1998 to pootify Microsoft's web site for better reading. :-)
We have already had one anonymous winner request to become non-anonymous.
No, that is not what I am saying. EC is more vulerable than RSA for a given key size where the CPU ops to perform the best known cracking algorithm are the same.
CPU-op equivalent EC searches require only a modest amount of memory and can be run in parallel with nil communcation requirements. CPU-op equivalent RSA searches require large working sets with matrix operations that do not lend themselves to parallel operations once the initial sieve is performed.
Even if you deploy a TWINKLE device in an RSA key crack that reduces the initial loading of the matrix to nil, the working set size of the matrix, the swap and/or system communication requirements become non-trivial for an CPU-op equivalent RSA key.
The paper suggests a way to improve some of the steps required (such as some of the linear algebra work) to factor using the Number Field Sieve (NFS) for large keys.
The paper does NOT give a method to improve the speed of cracking EC keys.
Special purpose hardware could reduce the cost of cracking an RSA key. However: The same could be said of cracking an EC key. Using different special purpose hardware and different performance tuning, one should be able speed up cracking of EC keys as well.
So ... If the existence of ideas to improve
the speed of cracking sufficiently large RSA
keys scares you and you worry about that
might come next,
then you should be even more worried about EC.
Why? Not because of the exact idea outlined in the paper. The paper does not apply to EC. Because EC is subject to special purpose hardware improvements: perhaps even more than RSA.
A common mistake that some people make is to assume that one only needs to count CPU cycles. The so-called "MIPS years" measurements.
Consider two keys that require the same number of CPU cycles to crack, one Elliptic Curve (EC) and one RSA. The EC key crack requires only a modest amount of memory, even for large EC keys. The RSA key (by factoring) requires a larger and larger working sets as the key size increases.
Consider the cracking a 256 bit EC key and the cracking of a 1620 bit RSA key by factoring:
So when I said two equivalently hard keys I should had said: two keys that require the same number of CPU operations to crack.
Two keys can require the same number of CPU ops to crack. However, a 256 bit EC key needs only a modest amount of memory and can be cracked on many machines running in parallel. A 1620 bit RSA requires a HUGE 120 TByte matrix sitting in a single address space where swapping and/or inter-processor communication become a major problem.
The methods described in the paper can be used to improve the cost of cracking EC discrete logs as well. The author, in a recent Usenet posting, points out that the paper's methods are likely to reduce the cost/effort of EC key cracking as well ... perhaps even more than RSA key
factoring.
The paper, combined with other other EC strength concerns suggests that EC is not the technology to turn to at the moment.
In other words, if this paper has you concerned about the security of RSA keys by factoring, then you should be even more concerned about the safety of Elliptic Curves as well.
But as others, including the author, have stated (in large friendly letters): DONT PANIC! It is not known if the ideas expressed in the paper are applicable to key sizes that are in common use.
Brute force EC does not require the memory size and bandwidth needed for things such as factoring in the Number Field Sieve (NFS). See:
for more details. In short: Given two equivalently hard keys, one EC and one RSA, the EC key will require memory and less memory/CPU bandwidth and will be cracked for less cost using the state of the art methods we known today. NOTE: These art includes: THINKLE and NFS improvements including those discussed in the paper (on which this discussion thread hangs).
Worse for EC: It is an active field of research. Every so often somebody publishes yet another eliptic curve special class that can be cracked much faster than brute force. In some cases it is very hard to determine if a given EC belongs to a weak key class. While these are mostly theoritical, the smart cryptologist will view them as troubling for EC key securiy at best.
In addition to the usual anti-spam methods:
one can block IP addresses that attempt to spam on a regular basis. Tools such
- ipchains
- netfilter/iptables
- ipFilter
can be configured to block frequent spammer IP addresses from your SMTP ports.The following is a list of IP addresses that we have observed spamming on a regular basis. Blocking these sites won't solve your spam problem. On the other hand blocking common spam locations as part of an overall anti-spam system will help.
Sorry if your IP address is in the above list. If you are not a spammer then it could be that you happen to be using an ISP that tolerates spammers (or is unable/unwilling to block them), or you work for a company that spam, or you are near a poorly configured and poorly maintained site that is abused as an open relay.
We have seen SNMP scans at a rate of about 17 per 3 hours (~5.6/hr) as ot 2300 PST.
Sorry.
The scans are talking the IP address space in pseudo-random order. It appears to hold the top 16 bits constant while walking the lower 16 in a pseudo-random order. We have not seen simple SNMP scans that just walk up the IP address range.
It appears that the tool is initially just looking for open SNMP ports. The tool could be simply collecting open SNMP ports for later system cracking.
What is exciting is about this result is they have achieved a very short controlled photon pulse of a non-trivial brightness.
They call themselves CCCP ... a pun intended
or an early April fools joke?
And their web site: Red background with Yellow letters. If not a visual pun, it shows poor color choice in terms of readability. If their web site is poorly designed, what else is in questionable shape?
Firstenberg refused to disclose his diagnosis, which allows him to collect disability income.
A book deal? Disability income? Enough said ...
For good measure, re-install your grub config by running:
Where /dev/hda is your boot disk.
For most PC users with IDE drives, it will
be /dev/hda .
Last, just reboot.
But will it survive a /.? :-)
There were many and frequent bright fireballs. During the peak of the storm (1015-1130 UTC), the sky was frequently filled with multiple meteors! Wow!