Cryptographers Break Commonly Used RC4 Cipher

Sparrowvsrevolution writes "At the Fast Software Encryption conference in Singapore earlier this week, University of Illinois at Chicago Professor Dan Bernstein presented a method for breaking TLS and SSL web encryption when it's combined with the popular stream cipher RC4 invented by Ron Rivest in 1987. Bernstein demonstrated that when the same message is encrypted enough times--about a billion--comparing the ciphertext can allow the message to be deciphered. While that sounds impractical, Bernstein argued it can be achieved with a compromised website, a malicious ad or a hijacked router." RC4 may be long in the tooth, but it remains very widely used.

Comments

Arcfour

[Hatta]

This is the cipher known as 'arcfour' in SSH. I use it regularly when speed is more important than security, which is frequently. I'm not sending a billion of the same files anywhere, so I will continue to use it.

Re:Arcfour

[i kan reed]

Ah, but what about when you're sending highly repetitive data, like a data table?

Re:Arcfour

[Hatta]

Then I'd enable compression.

Re:Arcfour

[Joce640k]

FTA: "Specifically, Bernstein showed serious cracks in TLS and SSL"

Seems it's not arcfour that's broken, its the specific combination of arcfour and TLS/SSL.

Re:Arcfour

[Joce640k]

Oh, wait, it's the arcfour key scheduling thing again.

This is an old arcfour weakness, not news. Everybody knows about it (and how to avoid it). The SSL people just never bothered to do it.

Re:Arcfour

[bill_mcgonigle]

I doubt you can peg your CPU with '-c blowfish'.

Re:Arcfour

[overmoderated]

This is also what is used by Google mail relays: version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);

Re:Arcfour

[X0563511]

Compression is deterministic. Compress the same data, you get the same output.

Re:Arcfour

[Anonymous Coward]

But the method depends on sending billions of identical packets. If you encrypt your billions of identical data, you should be left with only hundreds of millions of identical packets, and you'd be safe. If you're sending tens of billions of identical data over the internet, you should look for a better compression algorithm.

Re:Arcfour

[i kan reed]

You compress, encrypt, send, decrypt, decompress obviously.

Re:Arcfour

[TheCarp]

Thats what I have been using for years. In fact, in my last job when one of the DBAs was complaining about how long it took to transfer really large files with winscp, I showed her how to set blowfish as the cipher and she about started glowing she was so happy at the speed.

Re:Arcfour

[Hatta]

Irrelevant. As long as I only send one copy of the compressed data, it should be safe. A better objection is that it probably would take more CPU to compress the data before sending it over RC4 than it would to just switch to AES with no compression.

Re:Arcfour

[Hatta]

I think you'd be surprised at what CPUs I run SSH on.

Re:Arcfour

[Anonymous Coward]

Unless your CPU is made by Sun. Seriously slow CPUs for crypto.

Re:Arcfour

[Sulphur]

Compression is deterministic. Compress the same data, you get the same output.

42

Re:Arcfour

[WhiteDragon]

Oh, wait, it's the arcfour key scheduling thing again.

This is an old arcfour weakness, not news. Everybody knows about it (and how to avoid it). The SSL people just never bothered to do it.

According to the slides, this attack works by exploiting a bias in the output of RC4, not the key schedule at all...

Re:Arcfour

[bill_mcgonigle]

I think you'd be surprised at what CPUs I run SSH on.

I recall benchmarking an old Pentium-75 at 17Mbps with rsync over ssh, and that was, I think, 2001 (for an embedded x86 appliance I was working on). That was a 150MIPS machine. But, yes, the NetBSD folk do some amazing things, and anybody running a 16MHz Atmel is going to have a hard time pushing serious crypto. The new embedded chips with AES on-die are also lovely.

Re:Arcfour

[Anonymous Coward]

The SSL people never bothered to do it because SSL was defined before the weaknesses were published. The method to mitigate the problem makes it an entirely new algorithm. And there are much better algorithms to standardize than RC4+half-measures. The real problem is that vendors won't upgrade to these newer algorithms, such as AES-GCM.

Also, the well known measures didn't avoid the problem, they just kicked the bucket down the road. Once upon a time you only had to discard 256 bytes, then 768 bytes, then 1024 bytes.... The root of the issue is that RC4 is now a very weak cipher, and continues to get weaker. The actual permutations it generates are too biased. There may be ways to fix it, but nobody is seriously bothering to try because we already have much strong algorithms with security proofs.

Re:Arcfour

[Anonymous Coward]

Compress with some algorithms and the first few bytes are known - allowing for a known plaintext attack vector. Just zip something and see if it starts with PK - I bet it does.

Re:Arcfour

[Anonymous Coward]

54

For those really in the know, anyhow.

Re:Arcfour

[pthisis]

ssh's authors are smarter than that, they don't prepend a fixed header when enabling compression.

Re:Arcfour

[Anonymous Coward]

ECDHE-RSA-RC4-SHA is not plain RC4 go read :http://www.imperialviolet.org/2011/11/22/forwardsecret.html

Re:Arcfour

[slew]

As I understand it, ARC4 originally stood for 'Alleged' RC-4 since it was reverse engineered from RSA's proprietary RC4 implementation. The name RC4 is trademarked by RSA and they refuse to confirm that ARC4 was 100% compatible with their trademarked RC4, so for these two reason, the name ARC4 stuck.

Of course nobody today disputes that there is any actual difference between the public ARC4 and RSA's RC4...

Re:Arcfour

[X0563511]

Yes, but if you send the same file over and over, the compression isn't going to stop this attack from working.

Re:Arcfour

[Anonymous Coward]

Why do you want to send the same data over and over again ?

Why do you want to send the same data over and over again ?

Why do you want to send the same data over and over again ?

Re:Arcfour

[WaywardGeek]

I tried to beat ARC4 a decade ago, and had to admit defeat. It's a fine stream crypto system, so long as you have a solid nounce and drop the first few hundred bytes of output. I use ARC4-DROP(1024) in tinycrypt, a simple encryption tool I published on sourceforge because I couldn't find one that was simple. Back then, crypto gurus had found that with 1G of data they could determine that an encrypted stream of 0's was ARC4. I think that's been reduced to around 10Mb. So the question is "how do I make use of 1 part in 100 million non-randomness". Well, I guess such a plan involves sending the same data a billion times.

This attack requires that the encrypting server be compromised to allow a known plain text to be encrypted millions of times and the results published. If you're there already, you're in trouble. However, ARC4 remains useful in most streaming situations. Would you rather stick it out with an algorithm as well known and attacked as ARC4, or take a risk with the new kid on the block?

Re:Arcfour

[Forty Two Tenfold]

That's a stupid question.

Re:Arcfour

[Anonymous Coward]

Can't use compression, then the CRIME attack can be used.

Oh, come on ... heh.

[B3ryllium]

Many of the available PCI-type scanning tools seem to recommend it, so this is wonderful. Certainly sounds riskier than the recent BEAST vulnerability.

I'm sure this will lead to a few new entries on my gibsonindex.org cyber attack severity ranking project, as people find ways to apply this attack vector. :(

Anyone know what Cipher Suite configuration is the "safest" now? :)

Re:Oh, come on ... heh.

[bill_mcgonigle]

Anyone know what Cipher Suite configuration is the "safest" now? :)

You're screwed. You have the PCI people who are freaked out over CBC ciphers because of BEAST, you have lots of LTS distros not offering TLS 1.2, and you have people under FIPS who are your customers, so you wind up having to offer RC4 as a cipher to meet all of the above requirements. And even if you assume FIPS-managed clients will be controlling their ciphers to meet their internal requirements, you have to explain this to the PCI scanner vendor every. single. time.

If the LTS vendors could backport TLS 1.2, that would solve many headaches.

Re:Oh, come on ... heh.

[B3ryllium]

Yep, that's what I thought. Epic no-win scenario. :(

Maybe there's a way to Kobayashi Maru it.

Re:Oh, come on ... heh.

[Anonymous Coward]

I'm sure this will lead to a few new entries on my gibsonindex.org cyber attack severity ranking project

Yes we appreciate the shameless plug. But the joke's on you! Just about everybody here runs ad-blockers. So to quote Nelson: HAH-HAH!

Re:Oh, come on ... heh.

[B3ryllium]

The site doesn't have ads. It's got two amazon affiliate links on the About page (for the movie Hackers and a search of William Gibson's books), but that's it.

I'm just trying to do something good.

Re:Oh, come on ... heh.

[Anonymous Coward]

No one has managed to defeat Kobayashi Maru in over 80 years.

Re:Oh, come on ... heh.

[Kaenneth]

Use good encryption inside, and RC4 on the outside? (layered) Just like my Truecrypt volume on a Bitlocker'd drive.

Re:Oh, come on ... heh.

[viperidaenz]

Just like my double-ROT13 encryption on this message!

Re:Oh, come on ... heh.

[Kaenneth]

Sorry, your message is just gibberish, could you decode it?

Re:Oh, come on ... heh.

[Anonymous Coward]

While RC4 is 128-bit, it's not FIPS 140-2 approved. You are limited to 3DES or AES in FIPS environments.

Re:Oh, come on ... heh.

[broken_chaos]

Many browsers still don't support TLS 1.2 (which I feel should be treated as a serious bug, not a feature enhancement that some of those browsers treat it as). And those that do almost universally don't enable it by default.

So you'd still have to support RC4, for the moment.

Re:Oh, come on ... heh.

[Anonymous Coward]

That means changing the protocol and why do that when TLS1.2 already fixes these issues?

Re:Oh, come on ... heh.

[bill_mcgonigle]

You are limited to 3DES or AES in FIPS environments.

Yes, and in CBC mode if you want browser and openssl support, which leads back to the BEAST attack without TLS 1.2. Which is fine if the client is properly configured to avoid the attack - the server side can only help, not prevent. But the PCI Scanner vendors will redflag you for running any CBC ciphers.

Re:Oh, come on ... heh.

[martijn hoekstra]

Just like my double-ROT13 encryption on this message!

Typing in all caps is considered shouting, please refrain from it. Also, ROT13 is traditionally capitalised.

Re:Oh, come on ... heh.

[Anonymous Coward]

Anyone know what Cipher Suite configuration is the "safest" now? :)

What you want is AES-GCM. GCM is only supported by TLS 1.2

Failing that, AES-CBC is safe assuming you are patched for BEAST and Lucky 13.

Gmail uses RC4

[Iarwain Ben-adar]

Last time I checked, Gmail was negotiating RC4. For scale reasons?

Re:Gmail uses RC4

[heypete]

Yup. RC4 is really fast in software and so can scale really easily without needing any real change in server capacity.

Also, most browsers support Elliptic-Curve Diffie-Hellman key exchange with RC4 which provides perfect forward secrecy with substantially less computing overhead as using the standard DH key exchange protocols.

Hmm. Now to change some settings. Whee.

Re:Gmail uses RC4

[neokushan]

I'm still not sure how gmail is in any way vulnerable here? From the summary alone, it implies that you need to compromise something else to be able to inject data that's repeated a billion times. Given that gmail doesn't use a 3rd party ad service, it suggests that you'd need to compromise Google one way or another. Either that or the machine itself, in which case a keylogger would be much more effective, or the person's router, in which case there are still other easier attacks.

Jokes on him!

[Kenja]

I always change my message after the 999,999,999th time I send it with the same encryption key.

Re:Jokes on him!

[Anonymous Coward]

I know your comment is in jest, but it's worth noting the attack already assumes you use a different key for each transmission (just the same plaintext), also it's statistical so it already has a good chance of recovering some data after just a million transmissions, and even more so if the data is constrained (e.g., HTTP headers are always ASCII, but the "billion" number given in the summary is assuming near 100% recovery of the first 256 bytes of an *arbitrary* plaintext).

rfc4345

[cachimaster]

If I understood the article, the reported RC4 weakness is known since so long ago there is a RFC about it (rfc4345) that TLS implementation just ignores. SSH also uses RC4 in a non-vulnerable way, and that's why it's not broken, and it's perfectly possible to have a secure RC4 algorithm by simply discarding the first N bytes, where N>1000.

Re:rfc4345

[Anonymous Coward]

Take note of that date on RFC4345--2006. TLS was standardized long before that. And SSL was standardized even before RC4 weaknesses were known.

TLS 1.x could standardize RC4-dropN, but why bother? It's already standardized provably strong algorithms, but browsers don't bother to implement them. Why do you think they're bother to implement yet another new algorithm?

And N == 1000 is conjecture. Once upon a time 256 was enough. Then 512. Then 1024.

Re:rfc4345

[pthisis]

TLS 1.x could standardize RC4-dropN, but why bother? It's already standardized provably strong algorithms, but browsers don't bother to implement them. Why do you think they're bother to implement yet another new algorithm?

What "provably strong" bulk cipher algorithm is in TLS 1.x? AFAIK as of the latest version--TLS 1.2 (the latest)--only 3DES and AES are allowed as alternatives to RC4. A prove that either of those is strong would be a major result in the crypto world.

Re:rfc4345

[Anonymous Coward]

TLS 1.2 made it easier for clients and servers to negotiate new cipher suites. AES-GCM, which all experts agree is the best option today, is defined by http://tools.ietf.org/html/rfc5288

Several of Berstein's slides make fun of people who say, "oh, we'll just return to RC4". People keep bouncing around between the RC4 stream cipher and CBC block modes, when every expert has been saying for years we should ditch these and move to AES-GCM. But the browsers refuse to upgrade their TLS stacks.

Re:rfc4345

[pthisis]

That's all true, but has nothing to do with what I was discussing.

The post I was replying to implies that there's a new result proving that AES or 3DES is secure (which would have profound implications not only on cryptography but on greater questions of computability) or that there's a version of TLS that uses one time pads or something. I was attempting to get at exactly what was being claimed.

Find each permutation

[Anonymous Coward]

3
ab
abc
bca

Re:Find each permutation

[Anonymous Coward]

3 ab abc bca

Yes I am certain the hackers would NEVER think of that on their own!

Figures...

[Anonymous Coward]

I just went through my exchange server today disabling weak ciphers. Now this one will be on the list.

PCI scans and BEAST attack...

[rhavenn]

So, all the various PCI scanners tell you to use RC4-based crypto due to BEAST, which is pretty hard to pull off, now suddently we won't be able to able to use RC4 anymore, but TLS v1.2 and up aren't available in IE8 (XP) or older version of Firefox and I believe. So, now what?

Re:PCI scans and BEAST attack...

[LordLimecat]

Phase out vulnerable client software?

Re:PCI scans and BEAST attack...

[dragmar]

Use CBC with the TLS fix and if your PCI scanning vendor fails you for using CBC when its secure, tell them to go fuck themselves and use a real scanning vendor

WEP?

[Anonymous Coward]

isn't this similar to how WEP was broken?

Android 2.3

[tepples]

If the LTS vendors could backport TLS 1.2, that would solve many headaches.

You can't even be sure to have Server Name Indication on a smartphone. Entry-level smartphones still come with Android 2.3, whose TLS stack lacks SNI support, and without SNI, they can't see the certificate for more than one site on port 443 of a given IPv4 address.

Doctypes, images, etc.

[tepples]

it implies that you need to compromise something else to be able to inject data that's repeated a billion times.

If a known plaintext is good enough, you could use an image or just the <!DOCTYPE HTML><html><head> at the beginning of every HTML5 document. Or by "inject" did you specifically refer to chosen plaintext?

Re:Doctypes, images, etc.

[neokushan]

I'm referring to the summary itself:

Bernstein demonstrated that when the same message is encrypted enough times--about a billion--comparing the ciphertext can allow the message to be deciphered. While that sounds impractical, Bernstein argued it can be achieved with a compromised website, a malicious ad or a hijacked router.

The researcher himself has stated that you need to compromise the website. I suppose you're correct in that if you select a well known piece of data, you could be in there, but it must be more complicated than that. I would guess that you can't compare fragments of a message but rather the entire message is required, so you need to capture it all.

Re:Doctypes, images, etc.

[Anonymous Coward]

You don't need to see the entire message, only the same same encrypted portion that you're trying to decipher. And you need to see it over and over again, each time encrypted with a different key.

You then look at all the biases, which the RC4 stream generator is rife with (and not just the key schedule). And eventually you'll be able to deduce the plaintext. So, you don't need to know any plaintext, but you need the same unknown plaintext to be at the same position in the stream every cycle.

Obviously it's preferable if the plaintext you're trying to decipher comes earlier in the exchange, because then you can iterate the attack faster. If there's 4MB of stuff you don't care about beforehand, it'll be slow going.

Re:Doctypes, images, etc.

[viperidaenz]

You might have a hard time getting the !DOCTYPE... to be repeated a billion times on a single SSL session... I assume you have to start again when the SSL connection is renegotiated.

Re:Doctypes, images, etc.

[Carnildo]

Actually, a HTML document starts with something like

HTTP/1.1 200 OK
Date: Fri, 15 Mar 2013 02:18:32 GMT

followed by a bunch of other headers, before you get to the DOCTYPE and such.

Knowing that the document begins with "HTTP/1.1 200 OK" isn't very helpful, because as I understand it, this isn't a known-plaintext attack, but rather a constant-plaintext attack: RC4 as used by SSL/TLS doesn't produce the same cyphertext from a given plaintext every time. Ideally, there wouldn't be any correlation between cyphertexts of the given plaintext, but flaws in the cypher mean there are, and the attack uses these flaws to figure out what the plaintext is, given a sufficient number of encrypted versions of the same plaintext.

Chrome or Firefox

[tepples]

now suddently we won't be able to able to use RC4 anymore, but TLS v1.2 and up aren't available in IE8 (XP)

Show users of IE on Windows XP a countdown timer in days, hours, minutes, and seconds until the planned end of support for Windows XP. "Microsoft has announced that on April 8, 2004, it will stop providing security updates for your PC's operating system. In the meantime, we recommend accessing our web site using Google Chrome or Mozilla Firefox web browser. [ Get Chrome ] [ Get Firefox ]"

CORRECTION

[tepples]

I don't always catch all mistakes in preview. The correct date is just over a year from today, or April 8, 2014.

Re:Oh, come on ... fail.

[Anonymous Coward]

I'm just trying to do something good.

Feeding the trolls doesn't count.

Like the troll said: HAH-HAH!!

Shit, I actually use that one

[Anonymous Coward]

I've even been telling people to use it, in a local wiki. Oops. I docced how to make bru use a different machine's tape drive in broken-tape-drive emergencies, and suggested throwing in a "-c arcfour256" or "-c blowfish-cbc" for speed, but hadn't benchmarked which was faster so I didn't know which was best.

Now I know which one is best, I guess. (?) Not that it matters what cipher (I'd be happy to use none or rot13 in this use case) I use for an emergency backup or restore on a LAN, but ...

*sigh* Bring on the AES hardware. Not that it'll do much good with our machines from the year 2004...

Re:Shit, I actually use that one

[pthisis]

arcfour256 drops the first 256 bytes, which is done expressly to prevent a known attack against RC4. In addition, unlike a public https server an attacker can't force you to transfer a same-plaintext file a billion times via ssh. ssh with arcfour256 should still be fairly safe, though I'd certainly transition to AES in a timely fashion.

compromised website?

[Anonymous Coward]

If the website is compromised does the SSL connection matter anymore?

Just run it twice!

[tokiko]

If one pass of RC4 is too weak, just run it through again to make it ultra encrypted! :)

Re:Just run it twice!

[Subjective]

3RC4!

We still have double ROT13!

[sinij]

We will be fine, they haven't broken double-ROT13 yet!

RC4 has been broken for years

[DNX Blandy]

I run tests on RC4 years ago, run it thru a plain text file full of the same char repeated and then run through RC4, guess what? Oh the password is showing every 256 chars, hence the "weak" key. I developed a newer version of RC4 called RC64, uses a 64K (65536 or 256 ^ 2) key. The randomisation process is very complex and the algo was only just slightly slower than RC4, which is very fast anyway. A graphical representation of the 64K key visualized pure white-noise when the key was viewed in grey-scale. They need to start using mine me thinks :) Oh, and in a 50MB file full of the same repeated char, the password was not even hinted at and no 4 bytes were the same.

Re:RC4 has been broken for years

[PvtVoid]

I developed a newer version of RC4 called RC64, uses a 64K (65536 or 256 ^ 2) key. The randomisation process is very complex and the algo was only just slightly slower than RC4, which is very fast anyway. A graphical representation of the 64K key visualized pure white-noise when the key was viewed in grey-scale. They need to start using mine me thinks :) Oh, and in a 50MB file full of the same repeated char, the password was not even hinted at and no 4 bytes were the same.

Well, I'm convinced! Where can I invest in your company?

Re:RC4 has been broken for years

[Anonymous Coward]

How's your compressor that can compress everything really well coming along?

Re:RC4 has been broken for years

[DerekLyons]

A graphical representation of the 64K key visualized pure white-noise when the key was viewed in grey-scale.

What statistical analysis did you use to ensure your key was cryptographically strong?

Re:RC4 has been broken for years

[Anonymous Coward]

I did numerous analysis on the 50MB file and looked for: Any hint of the password truncated at numerous lengths from both ends and in the middle. Numerous lengths of byte data to check for repetitions in the file as this hints at a "weak" key. For the 64K key itself, I made sure the random rotation was working correctly and not pinning to certain parts of the key which can happen. I effectively wanted a "white-noise" effect on the key rotation which I obtained :)

Re:RC4 has been broken for years

[cryptizard]

I don't mean to discourage you from trying cool things, but this is exactly what NOT to do when considering cryptography. Creating a secure cipher is HIGHLY non-trivial and should not be attempted (or rather, your attempt should not be used to secure things) unless you understand the processes involved very well and are an expert. Just because the output "looks" random, does not mean it is secure. There are many random number generator algorithms that pass all statistical tests, but are trivial to predict because they are not built to be secure. The fact that you used such a large key is not a good sign because you are either (1) wasting space/computation or (2) relying on the entropy in your ridiculously large key to mask relations between your plaintext and cipher text, meaning you are not secure for larger files. A secure cipher, against which brute force is the best attack, requires a key of only 256 bits for the foreseeable future.

Re:RC4 has been broken for years

[DNX Blandy]

I'm no expert with regards to symmetric encryption granted, but I do know a lot about it. It makes RC4 look like plain-text in comparison. I disagree with regards to using a larger key as it means there is a lot more overlap when rotating the key, why have key(x) when you can have key(x, y)? It's technically as easy hence the speed is only just slightly slower, a fraction. The problem with keys that are 256 is the rotation. I came to the conclusion that there wasn't enough scope to randomize it enough hence the 64K key. I did numerous custom tests with a 256 key and I wasn't satisfied. It doesn't waste any computation and also I found it very good at securing large files. I still can't believe that RC4 is still used with the likes of WEP, SSL. In the end, it'll never get used and just be my own personal symmetric encryption algo :)

NoScript

[godel_56]

From TFA: "The gigantic number of identical messages that must be sent to break the scheme might seem reassuring. The attack in its current form takes close to 32 hours to perform. But Paterson points out that an attacker could use a malicious ad, a hijacked portion of a website, or a compromised router to feed the identical message to a user again and again unbeknownst to the victim.

NoScript is your friend, again.

Re:NoScript

[Anonymous Coward]

Or, ScriptSafe on Chrome.

Not just scale reasons

[Anonymous Coward]

Almost all parts of SSL in common use are compromised to some degree.

The BEAST attack (theoretically) compromises every common and strong SSL cypher other than RC4 and the march to newer TLS versions that offer protection for them is slow, not least in the webserver packages common Linux distros come with.

Re:WEP? Yes, similar idea

[billstewart]

RC4 provides reasonably good security as long as you don't use it for things it wasn't meant for. (Rule#1 of RC4 club is "Never encrypt the same stuff twice".) Bernstein's attack is interesting, because he's using TLS/SSL to push RC4 to do things it wasn't meant to do.

Help Get TLS Support in More Browsers

[utkonos]

TLS 1.1 support is enabled by default in Chrome. Read about that here.

If you want TLS 1.2 in chrome, please star this bug.

As for Firefox, TLS 1.1 and 1.2 support are still not ready. If you want to help, vote for this bug, this bug, this bug, and this bug.

The bugs to get TLS 1.2 support into Firefox are this one and this one.

Both Opera and IE support TLS 1.1 and 1.2. If you want to see this in Firefox and Chrome, vote for the bugs above. But, please don't comment on the bugs. That won't help.

Random cookies?

[manu0601]

RC4 was useful as a workaround for BEAST. Now we need to throw out RC4, we need another workaround for BEAST

The Right Way would be to use TLS 1.1 or TLS 1.2, but they re not supported by some browsers (e.g.: Mozilla).

What about working around the problem in the web server? BEAST relies on session cookies being at a fixed offset. If I add a random length cookie that is changed on each server reply, I understand I break BEAST assumption. Am I right? Writing an Apache module to do that would be quite straightforward. Perhaps it already exists?