wrote:
> ...
> So my question is, why do i need to random values m_A and n_A to compute
> the torsiongroup E[l_A] and respectively the kernel K_A ?
>
> Why does is not suffice to use only 1 point to generate E[l_A] and
> Kernel K_A ?
it is late, and i may mis understand,
yet the two are requisite for peers arriving at a shared secret by way
of these constructed isogeny; and the random values necessary to not
give too much (confirm secret values, without exposing secret values)
i found this paper a helpful expansion on the subject:
http://cacr.uwaterloo.ca/techreports/2014/cacr2014-20.pdf
"In this paper, we mainly explore the efficiency of implementing recently
proposed isogeny-based post-quantum public key cryptography..."
specifically the graph on page 5. note that the key exchange relies on
finding a path connecting vertices in a graph of supersingular
isogenies - thus a pair on both ends, not just a pair arrived at among
both participants.
if this is clear as mud, i will try tomorrow on a fresh brain :)
best regards,
From tiepelt at dev-nu11.de Thu Jul 9 05:58:05 2015
From: tiepelt at dev-nu11.de (Marcel)
Date: Thu, 9 Jul 2015 11:58:05 +0200
Subject: [cryptography] Supersingular Isogeny DH
In-Reply-To: <559E13D3.8040602@dev-nu11.de>
References: <54C5545F.3060600@gmail.com> <54C92127.5060900@dev-nu11.de>
<54C92732.70202@gmail.com> <54C9C907.5090501@dev-nu11.de>
<559E13D3.8040602@dev-nu11.de>
Message-ID: <559E45AD.4050909@dev-nu11.de>
well thanks for reply :)
The key exchange does not rely on using two different points.
I will try to explain i little more general:
I generate my l-torsion subgroup by two points:
= E[l]
During Key exchange i define my kernel using linear combination of
random values:
m, n
kernel = [m] * P + [n] * Q
So i wondered why i need two points. To generate the torsion subgroup it
would suffice to use one point:

= E[l]
And to generate the kernel the linear combination of one points would
suffice too:
kernel = [m] * P
So why is the protocol using zwo points for each? I that purely a
security issue to ensure that the torsion subgroup is no cyclic anymore?
regards,
On 07/09/2015 10:24 AM, coderman wrote:
> On 7/8/15, Marcel wrote:
>> ...
>> So my question is, why do i need to random values m_A and n_A to compute
>> the torsiongroup E[l_A] and respectively the kernel K_A ?
>>
>> Why does is not suffice to use only 1 point to generate E[l_A] and
>> Kernel K_A ?
> it is late, and i may mis understand,
>
> yet the two are requisite for peers arriving at a shared secret by way
> of these constructed isogeny; and the random values necessary to not
> give too much (confirm secret values, without exposing secret values)
>
> i found this paper a helpful expansion on the subject:
> http://cacr.uwaterloo.ca/techreports/2014/cacr2014-20.pdf
> "In this paper, we mainly explore the efficiency of implementing recently
> proposed isogeny-based post-quantum public key cryptography..."
>
> specifically the graph on page 5. note that the key exchange relies on
> finding a path connecting vertices in a graph of supersingular
> isogenies - thus a pair on both ends, not just a pair arrived at among
> both participants.
>
> if this is clear as mud, i will try tomorrow on a fresh brain :)
>
>
> best regards,
From jya at pipeline.com Thu Jul 9 10:12:06 2015
From: jya at pipeline.com (John Young)
Date: Thu, 09 Jul 2015 10:12:06 -0400
Subject: [cryptography] Caspar Bowden has died
Message-ID:
Privacy activist Caspar Bowden has died
https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=https%3A%2F%2Fnetzpolitik.org%2F2015%2Fdatenschutz-aktivist-caspar-bowden-ist-gestorben%2F&edit-text=
From noloader at gmail.com Thu Jul 9 10:25:33 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 9 Jul 2015 10:25:33 -0400
Subject: [cryptography] Caspar Bowden has died
In-Reply-To:
References:
Message-ID:
On Thu, Jul 9, 2015 at 10:12 AM, John Young wrote:
> Privacy activist Caspar Bowden has died
>
> https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=https%3A%2F%2Fnetzpolitik.org%2F2015%2Fdatenschutz-aktivist-caspar-bowden-ist-gestorben%2F&edit-text=
>
Oh wow.
We had dinner in Washington, DC last year. He was not old by any
measures, and he surely did not appear unhealthy.
Jeff
From davehowe.pentesting at gmail.com Thu Jul 9 11:34:34 2015
From: davehowe.pentesting at gmail.com (Dave Howe)
Date: Thu, 9 Jul 2015 16:34:34 +0100
Subject: [cryptography] Caspar Bowden has died
In-Reply-To:
References:
Message-ID: <559E948A.70907@gmail.com>
On 09/07/2015 15:25, Jeffrey Walton wrote:
> We had dinner in Washington, DC last year. He was not old by any
> measures, and he surely did not appear unhealthy.
http://www.theregister.co.uk/2015/07/09/caspar_bowden_dies_cancer_battle/
El Reg coverage says cancer.
Will be sorely missed :(
From paul at cypherpunks.ca Thu Jul 9 17:13:52 2015
From: paul at cypherpunks.ca (Paul Wouters)
Date: Thu, 9 Jul 2015 17:13:52 -0400 (EDT)
Subject: [cryptography] [Cryptography] Caspar Bowden has died
In-Reply-To:
References:
Message-ID:
On Thu, 9 Jul 2015, John Young wrote:
> Privacy activist Caspar Bowden has died
>
> https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=https%3A%2F%2Fnetzpolitik.org%2F2015%2Fdatenschutz-aktivist-caspar-bowden-ist-gestorben%2F&edit-text=
Caspar was instrumental to achieving privacy and fighting the
surveillance state. His achievements speak for themselves.
Personally, when I met him about 15 years ago when he was at FIPR,
he was an inspiration to me to keep working on privacy and ubiguous
encryption. That the fight for privacy is much bigger than a few crypto
geeks coding in their basement. He inspired and motivated me to keep
doing my little bits in the grand scheme of things.
Paul
From coderman at gmail.com Thu Jul 9 19:55:26 2015
From: coderman at gmail.com (coderman)
Date: Thu, 9 Jul 2015 16:55:26 -0700
Subject: [cryptography] Supersingular Isogeny DH
In-Reply-To: <559E45AD.4050909@dev-nu11.de>
References: <54C5545F.3060600@gmail.com> <54C92127.5060900@dev-nu11.de>
<54C92732.70202@gmail.com> <54C9C907.5090501@dev-nu11.de>
<559E13D3.8040602@dev-nu11.de> <559E45AD.4050909@dev-nu11.de>
Message-ID:
On 7/9/15, Marcel wrote:
> well thanks for reply :)
stumble toward the light, we can...
> The key exchange does not rely on using two different points.
Poorly worded; and a path needed two points not clear enough.
> I will try to explain i little more general:
> I generate my l-torsion subgroup by two points:
> = E[l]
>... define kernel = [m] * P + [n] * Q
ok.
> So i wondered why i need two points. [instead of]
>

= E[l] or even,
> kernel = [m] * P
i am looking for a visual representation of this key agreement
sequence; it's a weird beast like constructed modes of operation.
there are good elliptic curve demonstrations, but none covering
supersinguler EC DH
thanks for patience, may others be more helpful!
best regards,
From paunfilip at gmail.com Fri Jul 10 16:15:39 2015
From: paunfilip at gmail.com (Filip Paun)
Date: Fri, 10 Jul 2015 13:15:39 -0700
Subject: [cryptography] RSA signatures without padding
Message-ID:
Suppose I have a message M for which I generate an RSA-2048 digital
signature as follows:
H = SHA-256(M)
S = H^d mod N
Assume N = p*q is properly generated and d is the RSA private key.
And I verify the signature as follows:
S^e mod N == H'
where H' is the SHA-256 of the message to be authenticated. Assume e is the
RSA public key.
Since I've not used any padding then are there any flaws with the above
approach? What if e = 3? What if e = 2^16+1?
Your guidance is much appreciated.
Thank you,
Filip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From anzalaya at gmail.com Fri Jul 10 17:25:46 2015
From: anzalaya at gmail.com (Alexandre Anzala-Yamajako)
Date: Fri, 10 Jul 2015 23:25:46 +0200
Subject: [cryptography] RSA signatures without padding
In-Reply-To:
References:
Message-ID:
This paper probably helps answering part of your question :
http://www.iacr.org/archive/crypto2000/18800229/18800229.pdf
Note that you can't replace a random oracle by SHA256 but you might have
better luck with HMAC-SHA256 (https://eprint.iacr.org/2013/382.pdf)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From noloader at gmail.com Fri Jul 10 17:42:20 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Fri, 10 Jul 2015 17:42:20 -0400
Subject: [cryptography] RSA signatures without padding
In-Reply-To:
References:
Message-ID:
> Suppose I have a message M for which I generate an RSA-2048 digital
> signature as follows:
>
> H = SHA-256(M)
> S = H^d mod N
>
> Assume N = p*q is properly generated and d is the RSA private key.
>
>
> And I verify the signature as follows:
>
> S^e mod N == H'
>
> where H' is the SHA-256 of the message to be authenticated. Assume e is the
> RSA public key.
I *think* the signature could be malleable. That is, you could get
both S to verify, and N - S to verify. Whether its a problem (or not)
depends on your expectations.
> Since I've not used any padding then are there any flaws with the above
> approach? What if e = 3? What if e = 2^16+1?
Bernstein provides a really good history in "RSA signatures and
Rabin?Williams signatures: the state of the art",
http://cr.yp.to/sigs/rwsota-20080131.pdf. He discusses why various
steps are performed, like hashing the message rather than using the
message directly.
You should be OK with 3 or even 2, though it complicates signing.
Taking from Bernstein:
State-of-the-art systems use exponent 2 rather than
exponent 3. This speeds up verification, and improves
the signature-compression and signature-expansion
features discussed in subsequent sections. The signer?s
secret primes p and q are chosen from 3 + 4 Z to
simplify signing
Jeff
From mgreene at securityinnovation.com Fri Jul 10 18:45:54 2015
From: mgreene at securityinnovation.com (Michael Greene)
Date: Fri, 10 Jul 2015 15:45:54 -0700
Subject: [cryptography] RSA signatures without padding
In-Reply-To:
References:
Message-ID:
It is my understanding that, on a very basic level, using RSA without padding allows computing ?valid? signatures for new messages by combining two existing signatures, because a^d * b^d == (a * b) ^ d
The use of sha256 in this case probably makes this task slightly more annoying, but by no means impossible - it raises the bar only to crafting a message m where Hm(m) == H(m1) * H(m2) mod N. With padding the scheme becomes H = (PAD(SHA256(M))) which makes the resulting signature probabilistic rather than deterministic, and combining signatures to create new signatures no longer works.
It is also my understanding that the malleability problem with textbook (i.e. unpadded) RSA relates to encryption/decryption rather than signing/verification, not signing/verification, but I could be wrong about that.
--
Michael Greene
Software Engineer
mgreene at securityinnovation.com
> On Jul 10, 2015, at 1:15 PM, Filip Paun wrote:
>
> Suppose I have a message M for which I generate an RSA-2048 digital signature as follows:
>
> H = SHA-256(M)
> S = H^d mod N
>
> Assume N = p*q is properly generated and d is the RSA private key.
>
>
> And I verify the signature as follows:
>
> S^e mod N == H'
>
> where H' is the SHA-256 of the message to be authenticated. Assume e is the RSA public key.
>
> Since I've not used any padding then are there any flaws with the above approach? What if e = 3? What if e = 2^16+1?
>
> Your guidance is much appreciated.
>
> Thank you,
> Filip
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3298 bytes
Desc: not available
URL:
From jkatz at cs.umd.edu Fri Jul 10 18:59:24 2015
From: jkatz at cs.umd.edu (Jonathan Katz)
Date: Fri, 10 Jul 2015 18:59:24 -0400
Subject: [cryptography] RSA signatures without padding
In-Reply-To:
References:
Message-ID:
On Fri, Jul 10, 2015 at 4:15 PM, Filip Paun wrote:
> Suppose I have a message M for which I generate an RSA-2048 digital
> signature as follows:
>
> H = SHA-256(M)
> S = H^d mod N
>
> Assume N = p*q is properly generated and d is the RSA private key.
>
>
> And I verify the signature as follows:
>
> S^e mod N == H'
>
> where H' is the SHA-256 of the message to be authenticated. Assume e is the
> RSA public key.
>
> Since I've not used any padding then are there any flaws with the above
> approach? What if e = 3? What if e = 2^16+1?
>
> Your guidance is much appreciated.
>
> Thank you,
> Filip
This is a bad idea.
Note that the Full-Domain Hash (FDH) signature scheme would use a hash
mapping the message to all of Z*_N, where here you have a hash mapping
to the (much smaller) space of 256-bit strings.
The problem is that this makes attacks based on factoring H(m) (in
your case a 256-bit number rather than a 2048-bit number) and then
using multiplicative properties of RSA much easier. The size of e is
irrelevant.
From paunfilip at gmail.com Fri Jul 10 19:42:05 2015
From: paunfilip at gmail.com (Filip Paun)
Date: Fri, 10 Jul 2015 16:42:05 -0700
Subject: [cryptography] RSA signatures without padding
In-Reply-To:
References:
Message-ID:
Hello,
Thank you for your feedback. Please see my comments below.
On Fri, Jul 10, 2015 at 3:59 PM, Jonathan Katz wrote:
> On Fri, Jul 10, 2015 at 4:15 PM, Filip Paun wrote:
> > Suppose I have a message M for which I generate an RSA-2048 digital
> > signature as follows:
> >
> > H = SHA-256(M)
> > S = H^d mod N
> >
> > Assume N = p*q is properly generated and d is the RSA private key.
> >
> >
> > And I verify the signature as follows:
> >
> > S^e mod N == H'
> >
> > where H' is the SHA-256 of the message to be authenticated. Assume e is
> the
> > RSA public key.
> >
> > Since I've not used any padding then are there any flaws with the above
> > approach? What if e = 3? What if e = 2^16+1?
> >
> > Your guidance is much appreciated.
> >
> > Thank you,
> > Filip
>
> This is a bad idea.
>
Specifically, I am interested in the reasons why this is a bad idea for the
case where e = 2^16+1 and the hash is SHA256. Also, it's important to point
out that given my particular use case, an attacker can only see a few
pre-computed signatures and cannot generate any new signatures by using the
signer as a oracle.
> Note that the Full-Domain Hash (FDH) signature scheme would use a hash
> mapping the message to all of Z*_N, where here you have a hash mapping
> to the (much smaller) space of 256-bit strings.
My first impression was similar to yours where it just didn't feel right to
exponentiate a 256-bit number instead of a 2048-bit number. So now I'm
trying to search for an actual proof for why this would be bad.
> The problem is that this makes attacks based on factoring H(m) (in
> your case a 256-bit number rather than a 2048-bit number) and then
> using multiplicative properties of RSA much easier. The size of e is
> irrelevant.
>
Not sure what you mean by factoring H(m). Why would an attacker try to
factor H(m)? Do you instead mean finding the e-th root of H(m)? (My
assumption is that finding e-th roots in mod N is hard as claimed in RFC3447
.)
Thanks,
Filip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jkatz at cs.umd.edu Sun Jul 12 16:44:25 2015
From: jkatz at cs.umd.edu (Jonathan Katz)
Date: Sun, 12 Jul 2015 16:44:25 -0400
Subject: [cryptography] RSA signatures without padding
In-Reply-To:
References:
Message-ID:
On Fri, Jul 10, 2015 at 7:42 PM, Filip Paun wrote:
> Hello,
>
> Thank you for your feedback. Please see my comments below.
>
> On Fri, Jul 10, 2015 at 3:59 PM, Jonathan Katz wrote:
>>
>> On Fri, Jul 10, 2015 at 4:15 PM, Filip Paun wrote:
>> > Suppose I have a message M for which I generate an RSA-2048 digital
>> > signature as follows:
>> >
>> > H = SHA-256(M)
>> > S = H^d mod N
>> >
>> > Assume N = p*q is properly generated and d is the RSA private key.
>> >
>> >
>> > And I verify the signature as follows:
>> >
>> > S^e mod N == H'
>> >
>> > where H' is the SHA-256 of the message to be authenticated. Assume e is
>> > the
>> > RSA public key.
>> >
>> > Since I've not used any padding then are there any flaws with the above
>> > approach? What if e = 3? What if e = 2^16+1?
>> >
>> > Your guidance is much appreciated.
>> >
>> > Thank you,
>> > Filip
>>
>> This is a bad idea.
>
>
> Specifically, I am interested in the reasons why this is a bad idea for the
> case where e = 2^16+1 and the hash is SHA256. Also, it's important to point
> out that given my particular use case, an attacker can only see a few
> pre-computed signatures and cannot generate any new signatures by using the
> signer as a oracle.
The value of e is irrelevant, as the attack is based on the
homomorphic properties of RSA.
>>
>> Note that the Full-Domain Hash (FDH) signature scheme would use a hash
>> mapping the message to all of Z*_N, where here you have a hash mapping
>> to the (much smaller) space of 256-bit strings.
>
>
> My first impression was similar to yours where it just didn't feel right to
> exponentiate a 256-bit number instead of a 2048-bit number. So now I'm
> trying to search for an actual proof for why this would be bad.
>
>>
>> The problem is that this makes attacks based on factoring H(m) (in
>> your case a 256-bit number rather than a 2048-bit number) and then
>> using multiplicative properties of RSA much easier. The size of e is
>> irrelevant.
>
>
> Not sure what you mean by factoring H(m). Why would an attacker try to
> factor H(m)? Do you instead mean finding the e-th root of H(m)? (My
> assumption is that finding e-th roots in mod N is hard as claimed in
> RFC3447.)
No. The issue is that one can factor H(m), and with high probability
H(m) will even have small prime factors. You can then use an
index-calculus style attack to forge signatures.
The following papers have more details:
http://www.jscoron.fr/publications/padding.pdf
http://www.jscoron.fr/publications/isodcc.pdf
> Thanks,
> Filip
>
From paunfilip at gmail.com Sun Jul 12 17:55:52 2015
From: paunfilip at gmail.com (Filip Paun)
Date: Sun, 12 Jul 2015 14:55:52 -0700
Subject: [cryptography] RSA signatures without padding
In-Reply-To:
References:
Message-ID:
Jonathan,
Thank you for the links; very helpful.
Thanks,
Filip
On Sun, Jul 12, 2015 at 1:44 PM, Jonathan Katz wrote:
> On Fri, Jul 10, 2015 at 7:42 PM, Filip Paun wrote:
> > Hello,
> >
> > Thank you for your feedback. Please see my comments below.
> >
> > On Fri, Jul 10, 2015 at 3:59 PM, Jonathan Katz wrote:
> >>
> >> On Fri, Jul 10, 2015 at 4:15 PM, Filip Paun
> wrote:
> >> > Suppose I have a message M for which I generate an RSA-2048 digital
> >> > signature as follows:
> >> >
> >> > H = SHA-256(M)
> >> > S = H^d mod N
> >> >
> >> > Assume N = p*q is properly generated and d is the RSA private key.
> >> >
> >> >
> >> > And I verify the signature as follows:
> >> >
> >> > S^e mod N == H'
> >> >
> >> > where H' is the SHA-256 of the message to be authenticated. Assume e
> is
> >> > the
> >> > RSA public key.
> >> >
> >> > Since I've not used any padding then are there any flaws with the
> above
> >> > approach? What if e = 3? What if e = 2^16+1?
> >> >
> >> > Your guidance is much appreciated.
> >> >
> >> > Thank you,
> >> > Filip
> >>
> >> This is a bad idea.
> >
> >
> > Specifically, I am interested in the reasons why this is a bad idea for
> the
> > case where e = 2^16+1 and the hash is SHA256. Also, it's important to
> point
> > out that given my particular use case, an attacker can only see a few
> > pre-computed signatures and cannot generate any new signatures by using
> the
> > signer as a oracle.
>
> The value of e is irrelevant, as the attack is based on the
> homomorphic properties of RSA.
>
> >>
> >> Note that the Full-Domain Hash (FDH) signature scheme would use a hash
> >> mapping the message to all of Z*_N, where here you have a hash mapping
> >> to the (much smaller) space of 256-bit strings.
> >
> >
> > My first impression was similar to yours where it just didn't feel right
> to
> > exponentiate a 256-bit number instead of a 2048-bit number. So now I'm
> > trying to search for an actual proof for why this would be bad.
> >
> >>
> >> The problem is that this makes attacks based on factoring H(m) (in
> >> your case a 256-bit number rather than a 2048-bit number) and then
> >> using multiplicative properties of RSA much easier. The size of e is
> >> irrelevant.
> >
> >
> > Not sure what you mean by factoring H(m). Why would an attacker try to
> > factor H(m)? Do you instead mean finding the e-th root of H(m)? (My
> > assumption is that finding e-th roots in mod N is hard as claimed in
> > RFC3447.)
>
> No. The issue is that one can factor H(m), and with high probability
> H(m) will even have small prime factors. You can then use an
> index-calculus style attack to forge signatures.
>
> The following papers have more details:
> http://www.jscoron.fr/publications/padding.pdf
> http://www.jscoron.fr/publications/isodcc.pdf
>
> > Thanks,
> > Filip
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bakshi.puneet at gmail.com Sat Jul 25 14:01:38 2015
From: bakshi.puneet at gmail.com (Puneet Bakshi)
Date: Sat, 25 Jul 2015 23:31:38 +0530
Subject: [cryptography] What is the format to add multiple signatures (Would
PKCS#7 work?)
Message-ID:
Hi,
I want to add multiple signatures to a document. Which PKCS standard can be
used? Can PKCS#7 signature has the capability to add multiple signatures to
a document?
Regards,
~Puneet
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jya at pipeline.com Sun Jul 26 18:38:07 2015
From: jya at pipeline.com (John Young)
Date: Sun, 26 Jul 2015 18:38:07 -0400
Subject: [cryptography] Varoufakis claims had approval to plan parallel
banking system for Greece
Message-ID:
Varoufakis claims had approval to plan parallel banking system for Greece
http://www.ekathimerini.com/199945/article/ekathimerini/news/varoufakis-claims-had-approval-to-plan-parallel-banking-system
Allegedly aided by Columbia University IT professor to design a hack
of existing taxation systems.
Columbia Computer Science Faculty
http://www.cs.columbia.edu/people/faculty
From noloader at gmail.com Mon Jul 27 00:05:44 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 27 Jul 2015 00:05:44 -0400
Subject: [cryptography] Varoufakis claims had approval to plan parallel
banking system for Greece
In-Reply-To:
References:
Message-ID:
On Sun, Jul 26, 2015 at 6:38 PM, John Young wrote:
> Varoufakis claims had approval to plan parallel banking system for Greece
>
> http://www.ekathimerini.com/199945/article/ekathimerini/news/varoufakis-claims-had-approval-to-plan-parallel-banking-system
>
> Allegedly aided by Columbia University IT professor to design a hack of
> existing taxation systems.
>
> Columbia Computer Science Faculty
>
> http://www.cs.columbia.edu/people/faculty
Forgive my ignorance...
Is this one of Greenspan's disciples? Maybe one of Summer's friends.
(US Academia seems to publish whatever the US Financial sector wants
them to publish, regardless of how wrong it is. There are still
economists who swear by the experiment in Iceland, and how well
derivatives temper the US markets...).
I thought one of the cruelest joke on the Soviet Union's collapse was
the US sending economist to help the new Federation with their
economies back in the 1980s... That was around the time of the S&L
bailouts (and we were told that would never happen again...). And
Greenspan audited Keating's holdings, and extolled how healthy his
banks were....
Jeff
From johnl at iecc.com Mon Jul 27 01:26:00 2015
From: johnl at iecc.com (John Levine)
Date: 27 Jul 2015 05:26:00 -0000
Subject: [cryptography] Varoufakis claims had approval to plan parallel
banking system for Greece
In-Reply-To:
Message-ID: <20150727052600.83387.qmail@ary.lan>
In article you write:
>Varoufakis claims had approval to plan parallel banking system for Greece
>
>http://www.ekathimerini.com/199945/article/ekathimerini/news/varoufakis-claims-had-approval-to-plan-parallel-banking-system
>
>Allegedly aided by Columbia University IT professor to design a hack
>of existing taxation systems.
>
>Columbia Computer Science Faculty
>
>http://www.cs.columbia.edu/people/faculty
Pretty easy to tell who it is, there's three Greeks on the faculty but
only one does crypto.
Given the financial mess in Greece, it's perfectly reasonable to make
contingency plans for running the financial system if they get booted
out of the Euro and have to switch back to the drachma on short
notice. The crypto hackery does seem a bit odd, but nothing in Greece
seems to work the way one might expect.
R's,
John
From jya at pipeline.com Mon Jul 27 07:13:40 2015
From: jya at pipeline.com (John Young)
Date: Mon, 27 Jul 2015 07:13:40 -0400
Subject: [cryptography] Varoufakis ridicules GR taxation hacking story
In-Reply-To: <20150727103431.GA2558@sivokote.iziade.m$>
References:
<20150727103431.GA2558@sivokote.iziade.m$>
Message-ID:
twitter.com/yanisvaroufakis/status/625336067831558144
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From nikosft at gmail.com Mon Jul 27 07:28:00 2015
From: nikosft at gmail.com (Nikos Fotiou)
Date: Mon, 27 Jul 2015 14:28:00 +0300
Subject: [cryptography] Varoufakis ridicules GR taxation hacking story
In-Reply-To:
References:
<20150727103431.GA2558@sivokote.iziade.m$>
Message-ID:
The actual recording
https://twitter.com/OMFIF/status/625615275350736897 The quotes of the
original article
(http://www.ekathimerini.com/199945/article/ekathimerini/news/varoufakis-claims-had-approval-to-plan-parallel-banking-system)
are accurate
On 27 July 2015 at 14:13, John Young wrote:
> twitter.com/yanisvaroufakis/status/625336067831558144
>
>
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
From jya at pipeline.com Thu Jul 30 10:52:17 2015
From: jya at pipeline.com (John Young)
Date: Thu, 30 Jul 2015 10:52:17 -0400
Subject: [cryptography] William Friedman's 1955 Crypto AG visit reports
draft and final redactions
Message-ID:
William Friedman's 1955 draft Crypto AG visit report shows text
redacted in final version and vice versa. Two versions compared:
https://cryptome.org/2015/07/nsa-crypto-ag-compared.pdf
(20MB)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: