Re: [cryptography] Can there be a cryptographic dead man switch?
On 2012-09-19 17:01:02 -0400 (-0400), mhey...@gmail.com wrote:
[...]
If I should die, I will stop re-encrypting the secret and the trustee
(that I never really trusted) can break the public key and get to the
secret.
[...]
And how does the trustee get access to the encrypted form of the
secret? If he has a copy of it encrypted with the old key, how do
you ensure he throws it out when you reencrypt with the new key? If
he doesn't get access to the encrypted secret until you die, then
why not simply rely on that access mechanism and forget about
encrypting it in the first place?
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] non-decryptable encryption
On 2012-06-20 09:54:33 -0700 (-0700), Givonne Cirkin wrote:
curious, why don't some ppl trust link shortners? is that a
generation gap thing.
2nd. ur guesses are wrong. i was born in the USA. my parents were
born in the USA. my native language is English.
[...]
Perhaps this is also a generation gap thing. Professionals of my
generation converse with colleagues and peers by using complete
sentences and well-structured grammar. That same generation also
prefers canonical URIs and other accurate bibliographical
references/citations. I've been out of academia for a while, so
perhaps the major journals have begun to accept submissions via SMS?
To echo other responses on the paper, the biggest objection (aside
from the minimal novelty of the subject matter itself) is likely to
revolve around your non-decryptable terminology. Your method is
clearly not non-decryptable to the owner or intended recipient who
possesses the key/pad with which the data was encrypted, or else it
would be useless. Further, no encryption technique is particularly
useful when decryptable by unintended agents. As a result the term
adds nothing meaningful in context, being either a logical
contradiction or tautology (depending on your intended connotation).
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Is this as ominous as it sounds like? (It SOUNDS ominous as Hell - but maybe it isn't)
On 2012-05-07 12:53:14 -0400 (-0400), Randall Webmail wrote:
[...]
The Internet Kill Switch; With Global Wiretapping Capability?
[...]
I consider myself a paranoid nut, but that's a little far fetched
even for me. I'd take the time to write up everything that's off
base with it (from the perspective of working for an ISP and DNS
host), but it looks like someone already beat me to the punch:
http://metabunk.org/threads/561-Debunked-Markmonitor-com-The-Internet-Kill-Switch-Wiretapping
A fun flight of fancy nevertheless.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] trustwave admits issuing corporate mitm certs
On 2012-02-26 15:45:34 -0600 (-0600), Marsh Ray wrote:
[...]
So if the online banking site required TLS client authentication
with smart cards with on-chip RSA, the situation would be much
different. A MitM who succeeded in impersonating the site to the
user would be unable to replay or forward the user's credentials. In
theory, the user could not be socially engineered out of his
credentials (short of physically handing over his smart card).
[...]
Your login was successful, but due to recent security concerns we
also require a one-time verification of your personal information.
Please now enter the following...
* Checking Account Number
* Bank Routing Number
* ATM Card Number
* Card Expiraion Date
* CCV Number
* Full Name
* Billing Address
* Social Security Number
* Drivers License Number
Thank you for your cooperation. Please click here to log out and
back in again. [hyperlink to actual impersonated site]
So sure, maybe not socially engineered out of his online banking
credentials, just possibly everything else the attacker might want
in lieu of access to the banking portal itself. Mutual
authentication could thwart this if implemented well in a way which
was very visible to the user, but also might not if implemented
poorly (and it's not like banks are leading the way in
well-thought-out authentication technologies, after all).
Also working against this is that it's more expensive for banks to
step up authentication past the level which government regulators
consider to no longer be grossly negligent. Beyond there it's likely
cheaper in the long run for banks to refund disputed transactions
and replace compromised accounts (or wait for victims to get
frustrated and give up/leave in disgust).
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] this house believes that user's control over the root list is a placebo
On Sun, Jun 26, 2011 at 12:26:40PM -0500, Marsh Ray wrote:
[...]
Now maybe it's different for ISP core router admins, but the
existence of this product strongly implies that at least some admins
are connecting to their router with their web browser over HTTPS and
typing in the same password that they use via SSH.
[...]
Valid point, but flawed example. Managing these things day in and
day out, I can tell you this is the first thing any experienced
admin disables when initially configuring the device. If your admin
is managing your routers with a Web interface, SSL MitM is the
*least* of your worries, honestly.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Micro-SD card encrypts voice on mobile phones
On Thu, Dec 02, 2010 at 04:36:51PM -0500, Steven Bellovin wrote:
That's 521 bits for the ECC part, as I read it. An odd size, even
there?
[...]
...there is no 512-bit curve defined, but only one with a 521-bit
length...--IETF RFC 5639
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
