July 2018 - cypherpunks-legacy

[i2p] weekly status notes [mar 29]
by jrandom 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi y'all, time for the weekly status notes * Index 1) 0.5.0.5 2) UDP (SSU) 3) Q 4) ??? * 1) 0.5.0.5 Since y'all did such a great job at upgrading to 0.5.0.4 so quickly, we're going to have the new 0.5.0.5 release come out after the meeting. As discussed last week, the big change is the inclusion of the batching code, bundling multiple small messages together, rather than giving them each their own full 1KB tunnel message. While this alone won't be revolutionary, it should substantially reduce the number of messages passed, as well as the bandwidth used, especially for services like IRC. There will be more info in the release announcement, but two other important things come up with the 0.5.0.5 rev. First, we're dropping support for users before 0.5.0.4 - there are well over 100 users on 0.5.0.4, and there are substantial problems with earlier releases. Second, there's an important anonymity fix in the new build, that while it'd require some development effort to mount, its not implausible. The bulk of the change is to how we manage the netDb - rather than play it fast and loose and cache entries all over the place, we will only respond to netDb requests for elements that have been explicitly given to us, regardless of whether or not we have the data in question. As always, there are bugfixes and some new features, but more info will be forthcoming in the release announcement. * 2) UDP (SSU) As discussed off and on for the last 6-12 months, we're going to be moving over to UDP for our interrouter communication once the 0.6 release is out. To get us further down that path, we've got a first draft of the transport protocol up in CVS @ http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html?rev=HEAD Its a fairly simple protocol with the goals outlined in the doc, and exploits I2P's capabilities to both authenticate and secure data, as well as expose as little external information as possible. Not even the first part of a connection handshake is identifiable to someone that isn't running I2P. The behavior of the protocol is not fully defined in the spec yet, such as how the timers fire or how the three different semireliable status indicators are used, but it does cover the basics of the encryption, packetization, and NAT hole punching. None of it has been implemented yet, but will be soon, so feedback would be greatly appreciated! * 3) Q Aum has been churning away on Q(uartermaster), a distributed store, and the first pass of the docs are up [1]. One of the interesting ideas in there seems to be a move away from a straight DHT towards a memcached [2] style system, with each user doing any searches entirely *locally*, and requesting the actual data from the Q server "directly" (well, through I2P). Anyway, some neat stuff, perhaps if Aum is awake [3] we can wressle an update out of him? [1] http://aum.i2p/q/ [2] http://www.danga.com/memcached/ [3] damn those timezones! * 4) ??? Lots more going on, and if there were more than just a few minutes until the meeting I could go on, but c'est la vie. Swing on by #i2p in a few to chat. =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCSbNjWYfZ3rPnHH0RAi5qAKCNE+jorT/F1QPif4a1EPaTKg1DwwCggVy9 Kk+3I6WgqDjqaNKSc5xnoQA= =iXNV -----END PGP SIGNATURE----- _______________________________________________ i2p mailing list i2p(a)i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Re: [tor-talk] Tor and HTTPS graphic
by Paul Syverson 06 Jul '18

06 Jul '18

On Tue, Mar 06, 2012 at 08:15:58PM -0500, Mansour Moufid wrote: > On Tue, Mar 6, 2012 at 4:04 PM, Paul Syverson <syverson(a)itd.nrl.navy.mil> wrote: > > I'm a mere four years behind in putting my work up on the web, and > > this one wasn't co-authored so nobody else did either. I'll try to do > > something about that in my copious free time this week and send a > > link. > > Please do, this attack you mention is one I've been very interested > in. I'm sure many others would also love to read more about it. > I'll try to get to it soon. > It's time the myth of the GPA was challenged. I don't think active > correlation attacks can be defended against, but I think they can at > least be detected. Actually there are many papers over the last several years (e.g., at ACM CCS and Info Hiding) showing that one can place undetectable timing channels on flows (for some schemes provably undetectable for others practically undetectable). But passive correlation is adequate anyway, even at very low sampling rates (cf. Murdoch and Zielinski, PETS 2007). This is long known and well understood. It's why we have always said that onion routing resists traffic analysis not traffic confirmation. -Paul _______________________________________________ tor-talk mailing list tor-talk(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [cryptography] [info] The NSA Is Building the Country's Biggest Spy Center (Watch What You Say)
by Peter Maxwell 06 Jul '18

06 Jul '18

On 22 March 2012 17:02, Marsh Ray <marsh(a)extendedsubset.com> wrote: > On 03/22/2012 09:57 AM, Peter Maxwell wrote: > >> >> From >> >> http://blogs.computerworld.com/19917/shocker_nsa_chief_denies_total_informa… >> >> "Remember," former intelligence official Binney stated, "a lot of >>> foreign government stuff we've never been able to break is 128 or >>> less. Break all that and you'll find out a lot more of what you >>> didn't know-stuff we've already stored-so there's an enormous >>> amount of information still in there." >>> >> > In other words, they've accumulated a backlog of ciphertext. Encryption > working as designed. Depends on what you mean by "as designed" really. Personally, I'd presume as designed is to slow down or hinder an adversary, which would probably fit in this scenario. > > > Binney added the NSA is "on the verge of breaking a key encryption >>> algorithm." >>> >> > This sounds like budget boondoggle baloney to me. > > How can you be "on the verge" of something like that? > > You might have some ideas on how to attack it, but until they're proven > they're just guesses and likely to be dead ends. Not something you > should justify reworking your computing systems around. > > But once they're proven, you're not "on the verge". Meh, strictly speaking, yes, but if we're talking in practical terms it may be the case that they've figured out how to break some cryptographic primitive in significantly less time than the original design specifications but it would still take more computing oomph than they currently have. Fairly sure there was similar considerations about 64-bit RC5 in the late 90s - people knew it could be cracked by brute force, but took a distributed effort to prove as much (may have details slightly wrong as was long time ago and I can't be bothered looking it up). The scenario is not particularly likely though. > > > That sounds far more plausible than the previous explanations. I'd >> also suspect the "key encryption algorithm" may be RC4 and not AES >> at the moment. >> > > Or it could just be all the 40- and 56- bit stuff that was captured by > wiretapping Americans and not decrypted way back when the NSA felt > constrained by laws. > Hehe... "NSA constrained by laws", erm, yeah, I suppose there's a first for everything ;-) > > Or it could be everything using 512-bit RSA key exchange. > > Or it could be everything for which the security of the encryption > ultimately depends on a user-chosen password. E.g., MS-PPTP/MPPE (but > there's nothing really new about this). > > Or it could be a common protocol using a cipher weakly. For example, I > noticed this the other day about RDP "standard, non-FIPS" mode: > http://msdn.microsoft.com/en-us/library/cc240771%28v=prot.10%29.aspx > If the endpoints do actually manage to negotiate the use of 128 bit (as > opposed to 40 or 56 bit) security, it uses the output of RC4 without > discarding any initial bytes. Those initial bytes have some > correlations, some of which can expose the whole key. Just to make sure > the 1684 bit state size of RC4 doesn't get stale, the protocol refreshes > the key every 4096 packets. (Actually better than MPPE which seems to > rekey every 1 or 256 packets depending on negotiated options). > > Or it could be complete BS. In reality, they've probably got a lot of uses for more computing power and the chances of us ever finding out in our lifetime are slim. _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

FW: Recent Publication
by Somebody 06 Jul '18

06 Jul '18

Bob, The url below is wrong: try http://www.bankofengland.co.uk/fsr/ops.pdf instead. <Somebody> > -----Original Message----- > From: Somebody at The Bank of England > Sent: Friday, December 01, 2000 6:33 PM > To: Somebody > Subject: Recent Publication > > > You may be aware that we published a paper entitled 'Oversight of > Payment Systems' this week. It sets out our objectives for > payment system oversight and describes our role in practice. > The paper is available be on the Bank's website at > www.bankofengland.co.uk/fsr/payment. > > Please let me know if you would like a printed copy. > > Regards > > <Somebody at the BofE's .sig> --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

Re: [cryptography] Nirvana
by ianG 06 Jul '18

06 Jul '18

On 24/09/11 11:46 AM, James A. Donald wrote: >>> Also, what if we had real cryptographic money, with anonymity? In >>> other words: the payments system cannot be the trusted third party >>> for everything. > > On 2011-09-24 4:08 AM, John Levine wrote: >> Then malware would steal the crypto wallets. See Bitcoin. Yes. This is one reason why my system was built out of psuedonyms, with blinding as an added feature [0]. At the ultimate accounting, massive theft could be dealt with. With expense. I think I had to close out an account only once tho. > Yet Bitcoin, nonetheless, works. How's BitCoin doing? I saw two issues, being the lack of a substantial grounding in contractual valuation (design issue), and the rather dodgy hackability of the software (implementation issue). In the event, these two conspired to cause volatility that makes the big markets look like a calm sea... Fun to watch and play, not recommended to invest :P iang [0] Actually, DigiCash used the same design, they just hid it coz the cypherpunks didn't like it :) _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

FW: Recent Publication
by Somebody 06 Jul '18

06 Jul '18

Bob, The url below is wrong: try http://www.bankofengland.co.uk/fsr/ops.pdf instead. <Somebody> > -----Original Message----- > From: Somebody at The Bank of England > Sent: Friday, December 01, 2000 6:33 PM > To: Somebody > Subject: Recent Publication > > > You may be aware that we published a paper entitled 'Oversight of > Payment Systems' this week. It sets out our objectives for > payment system oversight and describes our role in practice. > The paper is available be on the Bank's website at > www.bankofengland.co.uk/fsr/payment. > > Please let me know if you would like a printed copy. > > Regards > > <Somebody at the BofE's .sig> --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

Re: [cryptography] Nirvana
by ianG 06 Jul '18

06 Jul '18

On 24/09/11 11:46 AM, James A. Donald wrote: >>> Also, what if we had real cryptographic money, with anonymity? In >>> other words: the payments system cannot be the trusted third party >>> for everything. > > On 2011-09-24 4:08 AM, John Levine wrote: >> Then malware would steal the crypto wallets. See Bitcoin. Yes. This is one reason why my system was built out of psuedonyms, with blinding as an added feature [0]. At the ultimate accounting, massive theft could be dealt with. With expense. I think I had to close out an account only once tho. > Yet Bitcoin, nonetheless, works. How's BitCoin doing? I saw two issues, being the lack of a substantial grounding in contractual valuation (design issue), and the rather dodgy hackability of the software (implementation issue). In the event, these two conspired to cause volatility that makes the big markets look like a calm sea... Fun to watch and play, not recommended to invest :P iang [0] Actually, DigiCash used the same design, they just hid it coz the cypherpunks didn't like it :) _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [liberationtech] /. ITU Approves Deep Packet Inspection
by Asher Wolf 06 Jul '18

06 Jul '18

>From http://committee.tta.or.kr : Revision of Y.2770 Requirements for #DPI in Next Generation Networks http://bit.ly/Yx0Sya (via @BetweenMyths) On 5/12/12 9:25 PM, Andre Rebentisch wrote: > Am 05.12.2012 10:27, schrieb Eugen Leitl: >> http://yro.slashdot.org/story/12/12/05/0115214/itu-approves-deep-packet-ins… >> >> >> ITU Approves Deep Packet Inspection >> >> Posted by Soulskill on Tuesday December 04, @08:19PM >> >> from the inspect-my-encryption-all-you'd-like dept. >> >> dsinc sends this quote from Techdirt about the International >> Telecommunications Union's ongoing conference in Dubai that will have an >> effect on the internet everywhere: > The WCIT is a "diplomatic conference" for the rules governing the ITU, > the ITRs. It seems wrong to mix that with ongoing specific > standardisation work of the ITU. > > Anyway, interesting discussions over at circleid.com: > http://www.circleid.com/posts/20121203_wcit_off_to_a_flying_start/ > Apparently ITU fellows are disgruntled that they cannot control the > media coverage and complain about all the "misinformation". > > Best, > Andri > > > -- > Unsubscribe, change to digest, or change password at: > https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [tahoe-dev] switching from introducers to gossip?
by Zooko O'Whielacronx 06 Jul '18

06 Jul '18

On Sun, Jul 1, 2012 at 9:51 PM, Brian <warner(a)lothar.com> wrote: > ... snipping out a lot of useful, clearly written details about the new introduction and accounting mechanisms ... > I think we can probably accomodate that. I'm optimizing for our two main use cases: friendnet and paid-service. > > In the friendnet, nearly all nodes are both a client *and* a server. This is not true of the grid I'm most familiar with: volunteergrid2. In that grid almost every node is either a client or a server -- almost no nodes act as both. (I think. This is just judging from reading the volunteergrid2-l mailing list.) Maybe we need two different names, one for the "p2p style" friendnet that you describe in your letter (partially quoted below) and the other for the "sysadmins offering one another access to their servers" friendnet, such as volunteergrid2. > The main question is whether nodes which are both clients and servers should have a single key, or two separate keys (I prefer a single key, because it makes reciprocal storage-permission grants easier). I don't understand enough to have an opinion on that specific question, but in general I think there is a growing tension between "p2p style" and "client/server style", and the above smells like baking "p2p style" into the introduction protocol. > What I really want is to make it super-easy for a new user to get their node running and connected to their friend's existing grid. And, more importantly, for that *first* friend to set up that grid. ... > The first friend (Alice) hears about Tahoe from her favorite blog, and installs it with her favorite package manager. ... > She hits the "Invite A Friend" button, ... > All grid members get a control panel where they can see who else is using their storage, allow/deny access, and control where their own node places shares. By default, anyone who gets invited to join the grid gets full access to storage on all members' servers, but access can be revoked at any time. I think that's great! I love the idea! I hope you keep working on it, and I will endeavour to help. If we succeed, it will be the long-awaited reincarnation of the Mojo Nation dream. But, it is rather different in deployment/management from what our current users do with our current software. Maybe it won't work out. It requires engineering effort to implement and maintain, makes the behavior of the software harder to predict, and introduces more complex failure modes. If possible, I would like to support people continuing to use Tahoe-LAFS as service administered by diligent sysadmins even while extending it to be deployable by inattentive end users as you've envisioned. I think not too far down this path there might come a time to split Tahoe-LAFS into separate packages targeted at different deployment scenarios. Note that the i2p folks appear to have already forked it for this reason -- in order to maintain different deployment features! Also note that you, Brian, have published some experimental forks/variants focused on different deployment patterns. If you want "user friendly p2p software", then you probably want: b" Which services? Each node operates, by default, multiple services -- storage server, storage client == web gateway, introducer/gossiper, and in the future other services like relay server (to help get around incomplete connectivity of the underlying network -- #445). b" Which IP addresses? Nodes automatically detect their own IP addresses, such as by inspecting the output of "/sbin/ifconfig" or "route.exe", or opening a TCP connection to some helpful STUNT/ICE server and asking that server what IP address your packets appear to be coming from (#50). b" Which connections? Nodes advertise multiple IP addresses / DNS names (possibly including those auto-discovered as above, plus any that were manually entered by the user (#754), plus 127.0.0.1 or any globally-non-routeable IP addresses revealed by ifconfig, and possibly in the future including indirection through a relay server), peers attempt to connect to nodes on all advertised IP addresses / DNS names in parallel, then use whichever connections succeeded. b" How to handle NAT/firewall/inconveniently-behaving-router? Nodes utilize the latest and greatest Romulan packet technology, such as UPnP (#49), "NAT hole punching" techniques (#169) or even B5TP (#1179) or relay service (#445) to breeze through such impediments as though they weren't even there. b" Reverse connections? If a TCP connection is established from node A to node B, then B can use that in the "reverse direction" to make requests of A, just as well as A can use it to make requests of B. This means that if A is behind a firewall which allows outgoing but not incoming connections to be established, and A established an outgoing connection to B, then B can use A as a server, but C, which for some reason didn't get a connection from A, cannot use A as a server. (#1086) If you want "sysadmin-friendly software" then you probably want the opposite of all these features! b" Which services? Each node operates, by default, only the services that the operator manually configured it to run. Even better you can install the software sufficient to run a specific kind of node, e.g. a storage server, without installing the software that would let it run other servers, such as introducers or storage clients (#1694). b" Which IP addresses? Nodes do not automatically detect their own IP addresses, but instead use only the IP address that their sysadmin manually told them to use. This is especially important for tor and i2p people where any auto-discovered IP address threatens the user's safety (#517). b" Which connections? You try to establish the prescribed TCP connection(s) to your server. If that fails, you log/announce failure. In the future you might even be able to configure it to run exclusively over HTTP(S) and then pass all of its connections through your HTTP proxies and Web Services tools (#510, #1007). (Although sysadmins may actually like the "try to connect to multiple IP/DNS addresses at once" feature, if it is sufficiently understandable and controllable to them. It would ease some headaches provided by the Amazon Web Services EC2 TCP/DNS infrastructure, for example.) b" How to handle NAT/firewall/inconveniently-behaving-router? If you can't establish a TCP connection to your prescribed target, then obviously you should not talk to it. Either some wise sysadmin doesn't want you to (firewall) or some stupid sysadmin has screwed up the network config and needs to fix it. In either case you should log failure and give up immediately. b" Reverse connections? Clients connect to servers. Servers do not connect to clients, clients do not connect to other clients, and servers do not connect to other servers (#344). To violate this principle means you will receive a visit from your keen-eyed sysadmin who will want to know what the hell you are doing B9. Don't get me wrong -- I think the p2p style, which foolscap already implements part of -- is sweet. I'd like to improve it, in the interests of making Tahoe-LAFS deployment more automatic for end-users. However, we should probably pay attention to the fact that many of our current users do not use those features, and some of them are actively requesting the ability to turn off those features. Maybe some kind of friendly fork or more targeted packaging would help us manage these diverging deployment scenarios? Regards, Zooko B9 https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1010#comment:18 https://tahoe-lafs.org/trac/tahoe-lafs/ticket/49# UPnP https://tahoe-lafs.org/trac/tahoe-lafs/ticket/50# STUNT/ICE https://tahoe-lafs.org/trac/tahoe-lafs/ticket/169# tcp hole-punching! https://tahoe-lafs.org/trac/tahoe-lafs/ticket/344# more client-vs-server refactoring: servers-only shouldn't subscribe to storage announcements https://tahoe-lafs.org/trac/tahoe-lafs/ticket/445# implement relay: allow storage servers behind NAT https://tahoe-lafs.org/trac/tahoe-lafs/ticket/510# use plain HTTP for storage server protocol https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517# make tahoe Tor- and I2P-friendly https://tahoe-lafs.org/trac/tahoe-lafs/ticket/754# merge manually specified tub location with autodetected tub location https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1007# HTTP proxy support for node to node communication https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1086# servers should attempt to open connections to clients https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1179# use N<TP https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1694# package client and server separately _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

RE: Schneier: Why Digital Signatures are not Signatures (was Re:CRYPTO-GRAM, November 15, 2000)
by None 06 Jul '18

06 Jul '18

The Word example actually has other worrying problems not mentioned. A Word document contains a lot of hidden information, including other versions. It would be quite easy to sign a Word document that, when you viewed it, looks significantly different then it could be displayed without violating the signature. This is due to numerous problems, the most basic of which is that we often don't sign what we view but instead some binary that we _believe_ represents what we viewed but often does not. This is not just theoretical nor esoteric, but quite easy as the Word example shows. In effect we have absolutely no idea what we are signing most of the time even without comprimise of keys, programs and all that good stuff. > -----Original Message----- > From: owner-cryptography(a)c2.net [mailto:owner-cryptography@c2.net]On > Behalf Of R. A. Hettinga > Sent: Wednesday, November 15, 2000 10:51 PM > To: dcsb(a)ai.mit.edu; Digital Bearer Settlement List; > cryptography(a)c2.net; cypherpunks(a)cyberpass.net > Subject: Schneier: Why Digital Signatures are not Signatures (was > Re:CRYPTO-GRAM, November 15, 2000) > > > At 5:58 PM -0600 on 11/15/00, Bruce Schneier wrote: > > > > Why Digital Signatures Are Not Signatures > > > > > >

1 0